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Rendezvous, Proximity Operations and Capture 
Quality Function Deployment 
Report 


1, Introduction 

Rendezvous, Proximity Operations, and Capture (RPOC) is a missions operations area 
which is extremely important to present and future space initiatives and must be well 
planned and coordinated. To support this, a study team was formed to identify a specific 
plan of action using the Quality Function Deployment (QFD) process. This team was 
composed of members from a wide spectrum of engineering and operations organizations 
which are involved in the RPOC technology area. 


& Background 

The key to this study's success is an understanding of the needs of potential programmatic 
customers and the technology base available for system implementation. To this end, the 
study team conducted interviews with a variety of near term and future programmatic 
customers and technology development sponsors. The QFD activity led to a thorough 
understanding of the needs of these customers in the RPOC area, as well as the relative 
importance of these needs. 


3* Sponsor's Perspective 

The sponsor of the RPOC QFD effort was Gregory C. Hite, Chief of the Navigation and 

Guidance Systems Branch in the Navigation, Control and Aeronautics Division at JSC. 

Benefits to be gained from the study are: 

a. A defined, logical approach for establishing a RPOC center of excellence; 

b. A plan to evaluate the state-of-the-art in hardware components and 
software algorithms necessary to implement auteri’tic RPOC 
functions; 

c. A plan to define an acceptable procedure for implements ion of automatic 

RPOC functions on both manned and unmanned vehicles; 

d. A plan for spending future advanced research and development funds to 
support the RPOC activity, 

e. Confidence in the derived RPOC master plan for achieving the center of 
excellence such that management advocacy exists to implement the 
proposed plan and potential RPOC implemented will come to this group 
for expertise; 

f. A means to establish agreed-upon action priorities; 

g. A long-range planning base for RPOC activities to be implemented over 
an extended period of time; 

h. Lasting RPOC team relationships. 
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4, Team fflaadlm 

Specific objectives of the RPOO QFD activity were: 

a. Collectively understand the elements, functions, and characteristics of 
RFOC, and the products delivered to customers; 

b. Define and prioritize the FY 91-93 activities of the RPOC community to 
meet customer needs; 

c. Define what the leadership could do, in addition to the RPOC community, 

to better meet the needs of customers. 

d. Establish boundaries for the activity which extend from low earth orbit to 
interplanetary missions for both manned and unmanned missions; 
ascent guidance is considered only as it affects the rendezvous phase. 


Team, Membership and Technical Contribution 

The RPOC QFD team included both civil service and contractor members, primarily from 
the JSC engineering and operations technical community, selected for their specific RPOC 
experience and expertise. The individuals involved are identified in Appendix A. 


6, QFD Concept 

Quality Function Deployment (QFD) is a formal technique for capturing a user's needs and 
mapping them into product and process parameters. It consists of techniques for creating 
and completing a series of matrices showing the association between specific features of a 
product and statements representing the "Voice of the Customer". In other words, it 
provides a structure for ensuring that customer's wants and needs are carefully 
considered, then directly transferred into an organization's internal requirements. 

The QFD methodology is a structured process that uses the construction of the House of 
Quality matrix to lead the team members through the process. The House of Quality matrix 
is a tool that quantifies the results obtained by the QFD team, and allows analysis at each 
step in the process. The QFD process and methodology are further discussed in Section 15. 


L RPOC Term Definitions 

Early in the RPOC QFD process it became evident that several of the key terms associated 
with Rendezvous, Proximity Operations and Capture, illustrated in Figure 1, needed to be 
defined to support a commonality of understanding, and approach. The following 
definitions were agreed upon by all team members, and used throughout the RPOC QFD 
process. 

7.1 Rendezvous 

Rendezvous is the mission phase in which a series of scheduled maneuvers adjust the 
orbital elements to achieve desired offsets in positu n and velocity relative to another body, 
such that the two bodies are brought into close proximity to each other with small relative 
velocity. 
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7.2 Flyby 

Flyby is the mission phase in which a series of scheduled maneuvers adjust the orbital 
elements to achieve decired offsets in position and velocity relative to another body, such 
that the two bodies are brought into proximity to each other rith large relative velocity. 

7.3 Proximity Operations 

Proximity operations is the mission phase which requires precision control of the relative 
position, attitude, and velocity between two vehicles and which is characterized ov frequent, 
small maneuvers. This phase includes flyarounds, approaches, departures, formation 
flying, stationkeeping, docking, berthing, tethering and other operations conducted at close 
range to another vehicle. 

Disting jhing criteria often used to establish the range fur the proximity operations 
zone include the following: 

- Where knowledge of the other vehicle's attitude is required for proper system 
operation of each vehicle; 

- Where loss of communications or inability to execute a translation maneuver 
unacceptably increases the risk of an immin ent, collision; 

- Ranges at which manual operations occur to maintain one vehicle in proximity to 
the other; 

- Ranges where plume impingement and contamination effects must be considered. 

Typically the proximity operation zone begins at a range of 2 kilometers. 

Note that the initiation of the proximity operations mission phase is not necessarily 
defined as the maximum range of the proximity operations sensor(s), since a given sensor 
may have long range as well as short range capabilities. 

7.4 Stationkeeping 

The procedure whereby a vehicle maintains a position relative to a second vehicle within a 
prescribed envelope, and during which the second vehicle does not execute translation 
maneuvers to maintain the desired relative position. 

7.5 Formation Flying 

The procedure whereby a vehicle maintains a position relative to another vehicle, or 
vehicles, within a prescribed envelope, and during which any of the vehicles may execute 
maneuvers. 

7.6 Attachment/Capture Procedures 
7.6.1 Docking 

A procedure that results in an attached condition between two vehicles by mechanically 
coupling the two vehicles together in a rigid fashion. The procedure requires a positive 
closure rate to activate the docking mechanism. 
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7A2 Berthing 

The procedure by which two vehicles are attached by means of a manipulator system on one 
of the vehicles. The procedure requires essentially zero relative rates between the two 
vehicles to effect capture. 

7.6.3 Tethering 

The procedure by which two vehicles are attached by means of a tether cable system. The 
tethered phase requires maneuvering by one or both vehicles to maintain stable conditions 
or conduct tethered operations. 


7.7 Operating Modes 

7.7.1 Autonomous 

A mode ii which a vehicle, or system, can evaluate and alter its operation to achieve its 
objective, without external supervision or control. 

7.7.2 Automatic 

A mode in which a vehicle, or system, can perform predefined operations without human 
intervention. 

7.7.3 Manual 

A mode in which a vehicle or -stem is operated by the vehicle crew. 

7.7.4 Teleoperafcetl 

A mode in which a vehicle or system is operated remotelv by a human. 

7.8 Vehicle Types 
7.8. J Active Vehicle 

The vehicle which performs translational maneuvers to effect a rendezvous. This vehicle is 
traditionally designated the "chaser" vehicle. 

7.8 2 , Passive Vehicle 

The vehicle which does not perform translational maneuvers to effect a rendezvous, but 
may perform maneuvers to enable a rendezvous. This vehicle is traditionally designated 
the "ta r °;et" vehicle. 


7.83 Cooperative Vehicle 

A vehicle which provides capabilities (e.g. command and control, sensor information or 
aid) for the enhancement or accomplishment of a rendezvous. 

7.8.4 Uncooperative Vehicle 

A vehicle which does not provide capabilities for the enhancement or accomplishment of a 
rendezvous. 


8. RPOC- Elements. Functions, and Characteristics 

The QFD team defined a typical RPOC scenario (Figure 1), then identified the elements, 
functions, and characteristics of RPOC that are required to be accomplished in the normal 
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9. Identification of Customers 

Initially the QFD team identified potential customers of RPOC technology. The list included 
government agencies, private space groups, universities, foreign nationals and industry, 
and served to identify the kinds of customers needing RPOC technology. Once the customer 
base was defined, this list served as a catalyst to tailor the questions to be asked each of the 
customers selected for interviewing. 

The list of RPOC customers (Appendix C) was developed to identify the breadth of the 
potential customers for interview; from this list interviewees were selected. The customer 
interview process is described in Appendix D. The interviews were conducted and reviewed 
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to identify the reeds of customers and prioritize these needs. The products to be delivered to 
the customers are in response to these needs, reflected in the list of general RPOC functions 
as covered in Appendix B. For example, a customer may desire new levels of reliability and 
fault tolerance in order to satisfy a mission requirement for an autonomous RPOC vehicle. 
Specifically, the need is for higher levels of reliability and fault tolerance for the RPOC 
vehicle and for the types of systems appropriate for autonomous operations. Generally, 
system (and vehicle) reliability and fault tolerance are included in the list of RPOC 
functions. 

The definition of the term 'customer' and the subsequent identification of who are RPOC 
customers is central to this QFD. In the purest sense, a customer is one who seeks tb 
products and services supplied by another, and expects to be satisfied. In this case, c * 
supplier is the RPOC community and the RPOC customers are identified by th; 
association with the members of the RPOC community. RPOC customers seek to satisfy 
their needs within the RPOC community. Programs or contractors may also seek to acquire 
an RPOC capability or, having the capability, may seek the services or products of other 
community members. In this sense most of the RPOC community are also RPOC 
customers; it should be no surprise that the total list of customers is comprised mainly of 
members of the RPOC community. 

This understanding and definition of a customer is both practical and appropriate, since 
the RPOC community members are identifiable as an unstructured group of professional 
individuals or organizations which practices aerospace engineering or operations in the 
RPOC arena, jr are known to have RPOC expertise. Alternatively, the RPOC co mmuni ty is 
defined as providers of the RPOC functions (See Appendix B). All organizations and levels 
are included if they have RPOC offices 01 contractors (who are tasked with RPOC functions) 
up to the program level. Also included are funding organizations if RPOC programs or 
research are supported by that organization. 

Central to the theme (and to the objectives) of . his study, is the definition of the term 'RPOC 
leadership'. The RPOC leadership are also numbers of community, but they are hard to 
distinguish. Formally, leadership seeks to manage and inspire a group to foster self 
improvement, attain identifiable goals, and produce. To the RPOC community, there 
appears to be no identifiable leadership, other than the program or contractor 
management. Although management seek goals (mostly programmatic) and productivity, 
this group does little to foster or inspire self improvement or goals which are community 
related. In these areas, the management seeks its guidance from the RPOC community 
itself and so RPOC community leadership is not within management. The responsibility for 
RPOC community leadership must rest on its most acrive members, esperia^y in the areas 
of advanced RPOC capability development, new technology development, product or quality 
improvements, process efficiency, and the coordination of such efforts. Establishment of an 
identifiable RPOC community leadership is essential to further RPOC advocacy. 


1fl >- individuals i n terviewed 

The team attempted to interview representative RPOC customers. Time constraints 
dictated that the number of interviews be limited to nine. Customers were selected who 
were expected to have RPOC needs, and were involved in a variety of programs. The 
customers chosen were: 
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Aldo Bordano, Deputy Chief, Navigation, Control and Aeronautics Division, Engineering 
Directorate, JSC. Mr Bordano is JSC point of contact for development of the NASA Code R 
Integrated Technology Plan which addresses how NASA will develop RPOC technologies. 

Harry J. Buchanan, Manager, Cargo Transfer Vehicle (CTV) Project Office, MSEC. The 
CTV currently envisions a need for automated rendezvouc and capture operational 
capability. 

Kenneth J. Cox, Chief, Navigation, Control and Aeronautics Division, Engineering 
Directorate, JSC. Dr Cox’s division is the lead NASA organization for the Exploration 
Technology Program for development of automated and autonomous rendezvous and 
capture technology. He is also chairman of the NASA Strategic Avionics Technology 
Working Group (SATWG) which is responsible for identifying gu' J ance, navigation, and 
control priorities, including RPOC. 

John D. DiBattista, Program Element Manager for Autonomous Rendezvous and Docking 
(AR&D), NASA Headquarters, Code RC. Mr. DiBattista is responsible for development of 
automated rendezvous and capture technology within NASA. 

Allan L. Dupont and David B. Weaver, Lunar and Mars Exploration Program Office, JSC. 
Messrs Dupont and Weaver are responsible <or mission development and operations in the 
Lunar and Mars Program Office. The current planning for flights to the Moon and Mars 
anticipate use of automated and autonomous rendezvous and capture technology. 

Claude A. Graves, J Chief, Systems Engineering Division, Engineering Directorate, 

JSC. Mr Graves is responsible for advanced systems concepts development and identifying 
technology requirements and issues. 

Fred Huffaker, Space Exploration Initiative, MSFC. Mr. Huffaker, in the Program 
Development Office at MSFC, is responsible for analyses, concepts, and requirements of 
transportation systems supporting missions to Mars. 

Mark B. Nolan, Manager, Technology and Commercial p ™>iecte Office, New Initiative 
Office, JSC, Mr. Nolan is responsible for coordination of technology development at JSC t 

the application of unique JSC expertise to engineering and operational problems in v 

RPOC area. 

Robert C. Ried, Chief Engineer, Lunar/Mars Exploration, Engineering Directorate, JSC. 
Dr. Rled is responsible for coordinating engineering solutions to the problems of Lunar and 
Mars exploration across tne many engineering disciplines at JSC. He also advises the 
Director of Engineering on application of JSC expertise to Lunar/Mars engineering 
problems involving RPOC. 


11. Findings and Results 

The Affinity/Tree Diagrams of the customer needs and technical solutions are shown in 
Tables 1 and 2. The results of the RPOC QFD process are shown in Tables 3 and 4 and 
Figures 2 and 3. 'The use of the House of Quality tool enabled the RPOC QFD team to focus 
upon the real drivers and identify which customer needs carried the highest ratings. 
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Although the top 3 customer needs were anticipated, the priority of some others was 
somewhat of a surprise to team members. 

What was more of a surprise for the team members, were the priorities of the technical 
solutions, although given the customer's needs, the heavy emphasis upon demonstration of 
technology was not surprising. The real surprise is that customers' need for demonstrated 
technology is not currently being met within the RPOC community, and customers felt this 
was a critical item. 

Good definitions of the customer needs and the technical solutions are critical for achieving 
a common understanding within the RPOC community This results in clearer direction 
and mutually satisfactory agreements among the numerous individuals and organizations 
involved. Accurate trade-offs and prioritization are essential to success. These important 
definitions are provided in Appendix E for use in evaluating these results. 
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Table 1. Affinity/Tree Diagram of RPOC Custom* rt^eds 


Lwel 1 Customer Need 

Level 2 Customer Need 

Levels Customer Need 

1.0 Systems Operability 

1.1 Optimize Degree of 
Independence 

1.1.1 Human Interaction 



1.1.2 System to System 


1.2 Ease of Use 



1.3 Elective Functional 
Partitioning 

1.3.1 Navigation 
Partitioning 

2.0 Meet Mission/ 
Program Objectives 

2.1 Unmanned Resupply 

2.1.1 Upgradable to Man 
Rated 


2.2 Autonomous RPOC 



2.3 Efficient Rendezvous 
Techniques 

2.3.1 Elliptical Orbit 
Rendezvous 


2 4 Efficient Proximity 
Op^ationB Techniques 

2,4.1 Minimize Vehicle-to 
Vehicle Interaction 



2.4. 1.1 Maintain Stable 
Conditions 



2.4.2 Minimize Plume 
Impingement 


2.5 Effective Space Traffic 
Control 

2.5.1 Collision Avoidance 



2.5.2 Ability to Control 2 or 
More Vehicles 

1 3.0 Low Program Risk 

3.1 Reliable Systems 



3.2 Demonstrated Systems 
& Technology 



3.3 System Acceptability 


4.0 Low Programmatic 
Cost 

4,1 Increase Design 
Process Efficiency 



4.2 Accommodate 
Technology 7 Growth & 
Insertion 



4.3 Increase Operations 
Efficiency 

4.3.1 Minimize 
Engineering Operations 
Maintenance Support 

5.0 Knowledgeable 

Comprehensive 

Consultation 
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Table 2. Affinity/Tree Diagram for RPOC Customer Technical Solutions 

Level 3 Technical Solutions | 


f' 


Level 1 Technical Solutions 

Level 2 Technical Solutions 

1.0 Design Philosophy 

1.1 Use Incremental Design 
Approach 


1.2 Use Simple Systems 

1.3 Use Redundant 
Components & Information 

i.4 Ueo Conservative Margins 

1.5 Use Standardized 
Interfaces 

1.6 Use Friendly Interfaces 

1.7 Define System 
Requirements for Minimum 
Training 

1.8 Use Failure Resistant 
Components 

1.9 Use Concurrent 
Engineering Process 

2.0 Collect & Exchange 
Knowledge 

2.1 Perform Survey of State of 
the Art RPOC Capabilities 


2.2 Build Databases 

2.3 Develop Integrated 
Technology Plan 

! 3.0 Develop Advanced 
| Technology 

3.1 Develop Advanced Sensors 


3.2 Develop Advanced 
Algorithms 

3.3 Develop Improved Docking 
Mechanisms & Facilities 

4.0 Define Mission 
Architectures Requirements 
ft Constraints 

4.1 Define Resupply/Return 
Mission Requirements 


4.2 Develop Traffic Control 
Strategy 

4,3 Define Operating Zones 

4.4 Define Operating Modes 

5.0 Define System 
Requirements 

5.1 Early Definition & 
Maturity of Requirements 


5.2 Improve System 
Requirements Traceability 
Process 

6 0 Define Operating 
Requirements 

6.1 Provide Effective 
Telemetry /C ommand/ 
Navigation Infrastructure 


S 

L- 
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| Level 1 Technical Solutions 

Level 2 Technical Solutions 

Level S Technical Solutions 


6.2 Reduce/Standardize 
Mission Dependent 
Reconfiguration 

6.2. 3 Reduce/Standardize 
Flight Software 
Reconfiguration 



6.2.2 Redr ^/Standardize 
Flight Turnaround 
Reconfig 

7.0 Design RPOC Systems 

7.1 Perform Functional 
Analysis on all RPOC 
Systems 



7.2 Develop Trajectory 
Approach Techniques 

7.3 Apply Expert Systems to 
RPOC 

7.4 Develop Algorithms for 
Rendezvous 

7.5 Design Attitude & 
Translation Control Systems 
to Minimize Contamination & 
Plume Impingement 

8 ,0 Evaluate RPOC Systems 
& Technologies 

8.1 Perform Systems & 
Technologies Trade Studies 

8.1.1 Analyze Tether 
Applications to Reduce 
Plume Effects 



8.1.2 Navigation 
Infrastructure 

8.2 Perform Simulations 

8.2.1 Non-Real Time 


8.2.2 Real Time 


8.3 Perform Hardware 
Evaluations 


8.4 Perform Statistical 
Analyses 

8.5 Perform Rapid 
Prototyping & Testing 

1 9.0 Develop & Maintain 
| Ccmmcn Tools & Facilities 

9.1 Automate Design Process o 
RPOC Systems 


9.2 Use Automatic Code 
Generation 

9.3 Automate Mission 
Planning (Ground) & 
Replanning (On-Board) 

10.0 Demonstrate RPOC 
Systems & Capabilities 

10.1 Perform Flight 
Demonstrations 

10.1.1 Conduct Shuttle Fligh 
Demonstrations 

11 

10.1.2 Conduct Unmanned 
Vehicle Flight 
Demonstrations 
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| Level 1 Technical Solutions j Level 2 Technical Solutions 

Level 3 Technical Solutions 



10.1.3 Conduct Multi- 
Vehicle Flight 
Demonstrations 

10.2 Perform Ground 
Demonstrations 

10.2.1 Conduct Prototype 
System Ground Tests 


10.2.2 Conduct Ground 
Tests with Flight 
Hardware 


Table 3: Relative Weight of Importance of RPOC QFD Customer Nee<ls 


Customer Need 

ikL&L 

3.2 

Demonstrated Systems & Technology 

22.4% 

2.2 

Autonomous RPOC 

14.4% 

2.1 

Unmanned Resupply 

9.5% 

2.3 

Efficient Rendezvous Techniques 

7.0% 

3.1 

Reliable Systems 

6.7% 

5.0 

Knowledgeable Comprehensive Consultation 

6.5% 

4.3 

Increase Operations Efficiency 

6.5% 

3.3 

System Acceptability 

5.3% 

2.4 

Efficient Proximity Operate ns Techniques 

5.1% 

4.1 

Increase Design Process Efficiency 

4 "% 

4.2 

Accommodate Technology Growth & Insertion 

4.6% 

1.1 

Optimize Degree of Independence 

3.0% 

1.3 

Effective Functional Partitioning 

2.0% 

1.2 

Ease of Use 

1.5% 

2.5 

Effective Space Traffic Control 

0.8% 
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Figure 2. linking of Customer Needs 



13 


Relative Weight ot Importance 



Ji^C- 25468 


Table 4. Technical Solutions to Cvr^omer Needs 


Technical Snlntinn t» Cnat/Mier Needs 

8.1 Perform Systems & Technologies Trade Studies 

10.1.3 Conduct Multi-Vehicle Flight Demonstrations 

10.1.2 Conduct Unmanned Vehicle Flight Demonstrations 

8.4 Perform Statistical Analyses 

8.2.1 Perform Simulations - Non-Real Time 

8.2.2 Perform Simulations - Real Time 

8.3 Perform Hardware Evaluations 

10.2.2 Conduct Groun A Teets with Flight Hardware 

10.2.1 Conduct Prototype System Ground Tests 

1.1 Use Incremental Design Approach 

10.1.1 Conduct Shuttle Flight Demonstrations 

8.5 Perform Rapid Prototyping & Testing 

3.2 Develop Advanced Algorithms 

3.1 Develop Advanced Sensors 

3.3 Develop Improved Docking Mechanisms & Facilities 
1.9 Use Concurrent Engineering Process 

9.3 Automate Mission Planning(Gnd) % ReplanningfOn-board) 

6.1 Provide Effective Telemetry/Comir and/Navigation Infrastructure 

6.2 Reduce/Standardize Mission Dependent Reconfiguration 

2.3 Develop Integrated Technology Plan 

2. 1 Perform Survey of SOA RPOC Capabilities 

2.2 Build Databases 

9.1 Automate Design Process of RPOC Systems 

6.2.1 Reduce/Standardize Flight Software Reconfiguration 

7.3 Apply Expert Systems to RPOC 

6.2.2 Reduce/Standardize Flight Turnaround Reconfiguration 

7.5 Develop Attitude/Translation Control Systems to Minimize Contamination & Plume Impingement 

7.2 Develop Trajectory Approach Techniques 

1.5 Use Standardized Interfaces 

4.2 Develop Traffic Control Strategy 

i .4 Develop Algorithms for Rendezvous 

5.1 Early Definition & Maturity of Requirements 

4.1 Define Resupply/Return Mission Requirements 

1.2 Use Simple Systems 

1.3 Use Redundant Components & Information 
1.8 Use Failure Resistant Components 

5.2 Improve System Requirements Traceability Proce cr - 

7.1 Perform Functional Analysis on All RPOC Sysisms 

1.6 Use Friendly Interfaces 

1.4 Use Conservative Margins 

4.4 Define Operating Modes 

4.3 Define Operating Zone 1 

1.7 Define System Requirements for Minimum Training 

9.2 Use Automatic Code Generation 


it ?i. Wt 
5.9% 
4.8% 
4.8% 
4.5% 
4.5% 
4.5% 
3.6% 
3.6% 
3.5% 
3.4% 
3.2% 
3.2% 
3.0% 
3.0% 
2 . 8 % 
2.7% 
2.5% 
2 . 1 % 
2 . 0 % 
2 . 0 % 
1.9% 
1.9% 
1.9% 
1.7% 
1.7% 
1.7% 
1 . 6 % 
1.5% 
1.5% 
1.5% 
1.4% 
1.3% 
1.2% 
1 . 1 % 
1 . 0 % 
1.0% 
1.0% 
0.9% 
0.9% 
0 . 8 % 
0.8% | 
0.8% 
0 . 6 % 
0 . 6 % 
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Figure 3A. Ranking of Technical Solutions to Customer Needs, Part 1 


Relative Weight of Importance 



RPOC QFD Results - Technical Solutions to 
Customer Needs, Part 2 



Relative Weight of Importance 
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12j Recommended EY 91-93 Activities to Meet Customer Needs 

The time interval of FY91-93 is short compared to the time needed to design, build and 
accomplish a project in space. However, the activities of the RPOC community in this 
interval should be focused on initiating efforts that can produce large results in the years 
following FY93. The major areas recommended for activity are identified in Sections 12.1 
and 12.2. They are inter-related and should be performed in parallel. 

The activities recommended here can be done only with management awareness, 
concurrence, approval, and support. These activities will require man-hours from specific 
personnel and some •’xpenditure of resources that require cost accounting by the 
participating organization. Management approval is required if the effort is to continue. 

A logical start for approval is with the management of the organizations that supported 
this RPOC QFD. They have the resources to support their activities and outside contacts to 
influence management in other needed organizations. Their support is crucial to the 
accomplishment of the tasks that follow. 

12.1 RPOC Community Fornatlon 

Until now, the RPOC community has been divided and segmer 3d by organization v e.g. 
NASA center, commercial company) and/or by program over how to equitably distribute 
and share the limited funding, manpower skills, and facilities needed for RPOC activities. 
After listening to customers from different programs and organizations say essentially the 
same things, and realizing that each does have the total resoi as necessary to 
accomplish their needs and goals, it is apparent that the organizations involved in RPOC 
nee ' the strength available from a cooperative forum. Therefore, it is recommended that 
the ustomers and implemented of RPOC establish such a forum. The goal of this 
organization is tc: 

Provide technical interchange and support among members, share 
resources, and advance the development of RPOC capabilities for future 
space endeavors. 

The formation activities should include the following: 

a. Establish contacts and lines of communication. Identify who the RPOC players are 
in government, industry, academia, and internationally. Where are they located? Who are 
the points of contact for each RPOC discipline? 

b. Identify resources. What are our capabilities and resources? What are our 
strengths and weaknesses? Establish mutual RPOC strategic plans consistent with NASA 
direction (i.e., funding, manpower, skills, data, equipment, facilities). 

c. Compile a list of activities. What are we doing in RPOC? What are the immediate 
needs? What are the long term needs? Identify and understand our customers, suppliers, 
and products. 

d. Begin to organize. How do we organize and structure our community to take 
advantage of collective strengths and effectively minimize redundancy and overlap? Will 


17 



* 


JSC-25453 

-V 

the organization be vague in the formal sense because of the many participants and ‘ : 
organizational agendas? How do we maintain an active and cooperative environment at the ' 

working level? 

e. Establish regular technical exchange meetings through existing forums (e.g. '< 

SATWG - Strategic Avionics Technology Working Group). t 

5 

12.2 Addressing Customer Needs. , 

Based on the current schedules for programs needing RPOC capabilities, it is essential that 
the immediate efforts in the RPOC community address the long-term customer needs. 

Based on the interviews with customers and discussions within the RPOC QFD team, there 
is one effort that seems to address the multiple needs of the RPOC customers: 
demonstrating RPOC capability in space with a level of independence beyond that of the 
manual modes currently used in the U.S. Space Program. An appropriate level of 
independence, considering both the needs of impending programs and the level of 


technology maturity, is a demonstration of automated (not autonomous) RPOC between two i, 

space vehicles. Such a demonstration would address the customer needs of unmanned i‘ 

resupply, system acceptability, and demonstrated systems and technology. It would 
partially address other needs: optimized degree of independence; effective functional ( 

partitioning; autonomous RPOC; efficient rendezvous and proximity operation*' techniques; i. 

and increased operational efficiency. i 


It is reasonable for this demonstration to use supervised automation (man-tending or 
monitonng with override capability), both to protect the investment in the mission and as a 
possible standard way of doing automated RPOC in low earth orbit in the fixture. 

Ways to conduct a reasonably priced flight experiment to demonstrate the concepts involved 
need to be explored. Conducting a Space Shuttle Detailed Test Objective (DTO), with free- 
flyers, is one option that was mentioned within the RPOC QFD team. 

To satisfy RPOC customer needs, the following are recommended for FY91-93: 

a. Further define, understand, and reach consensus on approaches for satisfying 
customer needs; 

b. Collect and analyze pertinent technology data and information; 

c. Examine options to demonstrate supervised RPOC automation in low earth orbit; 

d. Develop each option considering high level mission planning, vehicle choices, 
RPOC performance requirements, RPOC instrumentation choices, initial cost 
estimates; 

e. Select and advocate the most appropriate rad feasible option; 

f. Establish the options and/or coalitions available to fund such a demonstration; 

g. Aggressively se*»k fiin^ng. 
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1& What the RPOC Leadership Could Do to Better Satisfy Customer Needs 

The RPOC QFD team spent considerable time and effort to define and prioritize RPOC 
activities necessary to meet customers needs. The next task is to define, create, and execute 
the mechanisms required to "reet the needs of the customers. Oversight of RPOC 
technology development should be more centralized, and placed in a small and 
knowledgeable steering group. The steering group, specifically responsible for RPOC 
technology, should be established to guide all RPOC technology activities. This multi- 
organization group should be formed within the RPOC technical development community. 
Ultimate responsibility for development and operation would not rest with the group; 
rather, the group would be the advocate for RPOC. It would know where the expertise 
resides, and be aware of current and future activities. It would maintain a database of 
reference information about RPOC technologies. Leadership of the group should rotate 
annually among its members. In short, it should be the focal point for all RPOC activities. 

It is not difficult to identify program managers who support the need for RPOC 
development. What is difficult, however, is to find program managers who are willing 
and/or able to support RPOC development with funding and personnel. RPOC technology is 
easily transferred between programs, thus preventing duplication of effort. However a non- 
programmatic sponsor for the technology i3 needed during Phases A & B, with specific 
program application and customization in Phases C & D. This is a difficult situation which 
must be addressed. Customers have a need for RPOC capability, yet RPOC capability will be 
slow in developing if funding and personnel support are not forthcoming. This, then, is the 
dichotomy. Customers need demonstrated RPOC capability. Yet, without adequate funding 
and personnel, the demonstrated capability will not occur in a timely fashion to meet the 
customers' needs. 


14L Recommended Future Activities 

The RPOC Quality Function Deployment process was effective in identifying customer 
needs and in defining promising approaches to satisfying those needs. 

The top three customer needs - demonstrated systems and technologies, autonomous 
rendezvous proximity operations and capture, and unmanned resupply - are interrelated. 
The top potential technical solutions - trade studies, unmanned flight demonstrations, 
multi-vehicle flight demonstrations, statistical analyses, and Shuttle flight demonstrations 
- indicate a strong desire to augment analysis and ground demonstrations with flight 
demonstrations of hardware under actual conditions, a*-J a need to reduce the development 
risk placed on new programs. 

The use of demonstrated systems and technologies is one way to reduce risk and minimize 
development costs for new programs. The development of unmanned resupply capability is 
an excellent method of developing and demonstrating RPOC technology systems and 
technology. The development of an unmanned resupply capability also reduces both 
resupply risk and cost via the use of expendable launch vehicles. The risk to human lives is 
removed, the risk of launching low-value items with a high-value national asset (the Space 
Shuttle) is removed, and the cost of delivering the items can be reduced by using a lower 
cost vehicle with potentially smaller gro. nd operations requirements. It has the added 
benefit of being demonstrable in low-earth orbit using technology that is largely available. 


19 




JSC-25458 

The development of an autonomous RPOC capability can reduce operational costs even 
further by reducing or eliminating dependence on ground command and control 
operations, or by eliminating the need for expensive command and control infxastructures. 
This capability can build on the success of an unmanned resupply capability in low-earth 
orbit. Autonomy is an essential capability for unmanned planetary missions requiring 
multiple vehicles, and may be required for manned missions as well. 

The challenge is to provide a focus for the efforts of the RPOC community which will enable 
NASA to: 

• advance RPOC technology in a number of technically challenging areas; 

• establish intercenter and govemment/'industry/academia working re 1e \tionships; 

• build momentum and enthusiasm; 

• provide tangible evidence of progre3s; 

• provid flight performance data for use by current and future programs; 

• remove traditional impediments to rapid development of new systems; 

• use limited funds most effectively. 

The Exploration Technology Program has planned technology development of autonomous 
rendezvous and docking capability, emphasizing requirements development, and ground 
demonstrations. A logical extension of that plan is flight demonstration aimed at proving 
concepts and components. The DOD Delta Star project demonstrates tha 1 , given a clear set 
of objectives, reasonable funding, and a maximum amount of delegated responsibility, 
concepts can be turned into missions in a relatively short period of time. 

A plan for a Shuttle flight demonstration should attempt to use a maximum amount of off- 
the-shelf components in progressively more sophisticated Detailed Test Objectives (DTOs). 
These missions could use low-cost, functional test vehicles which exist only to provide 
platforms for the systems to be tested. An existing vehicle such as SPAS (Shuttle Pallet 
Satellite) could be modified to provide a target vehicle. These vehicles could be launched and 
retrieved by the Space Shuttle, and could be combined with other missions for effective 
Shuttle utilization and reduced cost. The flight demonstrations could be structured in the 
following sequence: 

• Flight 1 - demonstrate automatic proximity operations and capture with a 

passive target; 

•Flight 2 - demonstrate completion of automatic near-field rendezvous 
maneuvers with a passive target PLUS automatic pro imity operations 
and capture; 

•Flight 3 - demonstrate completion of automatic far-field rendezvous 
maneuvers (orbit insertion on) with a passive target PLUS completion of 
a automatic near-field rendezvous maneuvers with a passi/e target 
PLUS automatic proximity operations and capture. 

This flight program would demonstrate all ground and onboard functional aspects of 
rendezvous, proximity operations, and capture required for unmanned resupply. The 
program would clearly establish a focus for RPOC technology development, and would 
satisfy J he objectives mentioned above. An autonomous capability would come later. 

Other, more modest fixture activities of high value include: 
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• Close joint JSC, MSFC, and NASA HQ involvement in additional QFD 
efforts that either modify or build upon this report. 

• Expansion of the customers interviewed to include pertinent DoD, NASA 
HQ Code M, and industry organizations involved in RPOC activities. 

Their needs could then be folded into the existing RPOC QFD House of 
Quality to see if the hierarchy of needs is significantly affected. 

• Establish a periodic forum for RPOC related technical interchange, and 
invite all members of the government, industry, and academia RPOC 
community to participate. 

• Establish a focal point for the collection and dissemination of RPOC 
related requirements and performance data to maximize the use of 
scarce resources and decrease duplication of effort. 

• Undertake a RPOC community-wide survey of simulation and analysis 
capabilities to catalog the capabilities and ensure com-ir * j of 
simulation and analysis results within the RPOC community. 

• Periodically review what are the RPOC needs with the t ier 
community and update the QFD together with appropriate adjustments 
in the technical solutions as to how we satisfy customer needc. 


15* BPJPg-flFP -PJQC9S3 and Methodology 

First application of the QFD process was in the Kobe Shipyard of Mitsubishi Heavy 
Industries in 1972. It was introduced to the US in 1983. The QFD process offers many 
benefits. It promotes effective communication, reduces changes as design enters 
production, and decreases time for design and production phases. It also allows for 
prioritization of product and process parameters along with early identification of 
hardware design features. Additional QFD benefits include identifying targets for cost 
reduction, reliability, flexibility for individual tailoring, and provisions for engineering 
breakthroughs. 

However, the QFD process is not without its challenges. Although it is perceived as being 
complex, the process has an exact "cookbook" form. The process requires minimum 
training, but the QFD team must adhere to the procedures. The process requires the full 
attention of the QFD team for the duration of the task. Because of this, management 
support for the project is essential. Team members must be given time away from their 
other duties to do a credible QFD job. 

There are two generally accepted QFD techniques. They are the Four Phased approach and 
the Matrices of Matrices approach, both having common goals and elements. Both methods 
drive towards specific means to develop technical requirements, and put emphasis on 
setting priorities at ea Ji stage of development. Both provide for the consideration of cost, 
reliability, new concepts or technology, and for the use of additional tools and techniques as 
appropriate. 
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As with any process there are requirements for success. First, and foremost, is a strong 
commitment by management to the effort. The QFD process requires dedicated 
participation by individuals who represent all applicable engineering and operations 
functions. To be successful, the QFD group needs to be of controllable size, usually 10 or 
less individuals, and every member of the QFD needs to have good listening skills. In 
addition the QFD facilitator needs a broad understanding of the project and excellent 
communication skills. It is critical to get the right team members who possess appropriate 
knowledge, and allow adequate time for preparation and for team members to overcome a 
sense of vulnerability. 

The QFD process starts with the QFD team identifying who the customers are and 
preparing a plan for gathering and analyzing information about the customers. The 
customers are interviewed to identify their needs. Following the interviews, the interview 
teams prepare write-ups that identify the customer's needs and separai .. them from 
customer identified solutions. The write-ups are reviewed and agreement received from 
the customer. The needs are then listed without evaluation of their merits. The QFD team 
conducts a brainstorming session to establish the Affinity and Tree Diagrams for the 
customer needs. The Affinity Diagram is a grouping of customer needs that 8"e similar to 
each other and have " common title. (See Tables 1 & 2 for the Affinity/Tree Diagrams for 
customer needs and technical solutions.) The Tret Diagram, some tiiv.es referred to as an 
Affinity/Tree Diagram, is the hierarchical organization applied to th*» Affinity Diagram. 
Once a hierarchy is established for the Affinity/Tree Diagrams, the key customer needs are 
identified, and definitions for each of the key customer needs developed. Thet. definitions, 
discussed in Appendix E, help to ensure consistency when evaluating the customer needs 
later. The key customer needs are now transferred to the Ho^ae of Quality (Appendix F). 

Next step in the QFD process is to identify the relative degree of importance of each key 
customer need, based upon the QFD team members knowledge and their perception of how 
a customer would rate his identified needs. Not every customer need will be rated for each 
customer, only those mentioned in the interview with a specific customer. 

Next is an evaluation of how well customer needs are currently being met, and the relative 
degree of planned improvement in the future. The team must define how far into the future 
they will be evaluating the customer needs. When evaluating the relative degree of 
improvement, the plans and resources needed to implement the improvements should bu 
realistic, (i.e. don't plan on a 200% improvement, but only have funding tc get 25%. ) 

Within the list of customer needs, there are probably several needs which, if solved, would 
create excitement within the customer base. These specific needs are urgently sought by u, 
single customer, or by several customers; solving these needs would generate significant 
amounts of business for an organization. These are called sales points and should be 
identified from among the existing customer needs. Generally, there are only 2-3 major 
sales points, and an equal number of minor ones. With the completicn of these 
determinations, a relative weight of importance of the customer needs can be calculated. 
These weights are used as a guide for selecting the key customer requirements on which to 
concentrate time and resources. 

The next major step in the QFD process is to identify technical solutions to the customers 
needs. This list is developed within the QFD team using existing data, combined experience 
from team members, and technical interchanges with the customers. Brainstorming is 
used to identify additional technical solutions that may not have been previously noted. In 
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addition, customer ideas for technical solutions are also noted. The information is then 
organized using the Affinity/Tree Diagram process to identify any gaps. Identifying gaps 
permits the team to make sure that every customer need has at least one technical solution 
associated with it. Once the technical solutions have been identified, clearly understood 
definitions for the technical solutions (see Appendix E) are developed so that all team 
members understand what the technical solutions mean. 

Following identification of the technical solutions, a relationship matrix is developed which 
indicates the relative strength of a technical solution to satisfy a customer need The 
technical solutions are evaluated by the QFD Team on the basis of strong, moderate, weak, 
or no relationship between the technical solution and the customer need. For a large 
matrix, QFD team members can be divided into groups to complete segments. Once each 
group has completed their segment, the completed chait can be reviewed by the entire QFD 
team. The team should not expect relationships beWeen each pair. Also, a technical 
solution which does not address any of the customer needs is suspect; it indicates that a 
customer need may not have been identified, or the technical solution may be unnecessary. 

The importance weight of the technical solutions is computed for each technical solution 
that has a relationship with a customer need, by taking the sum of a strength of association 
value (9,3,1, or 0) assigned to the relationship determined in the relationship matrix times 
the relative weight of the customer needs that correlate that technical solution. This 
importance weight is then normalized to determined the relative weight of the technical 
solutions. Thece relative weights indicate the potential priority of technical solutions, 
which then must be balanced against available resources, the difficulty of providing the 
technical solution, the potential for a breakthrough, or the need for improvement in a 
particular technical area. 

Next a technical comparison is conducted, identifying how well the RPOC community is 
capable of satisfying each technical solution. Specific target values are assigned to as many 
of the technical solutions as possible to define specific goals/ranges for designers, and 
establish targets for later trrde studies and analysis (See Appendix J). Each target value 
must be agreed upon by the Team, and be measurable. 

The last procedure is to conduct a comparison of the technical solutions against each other. 
This comparison, known as a correlation matrix, assists in identifying trade-offs and 
interactions. The completion of this step puts the top on the House of Quality and completes 
the development of the House of Quality tool. The tool is then analyzed to identify the 
priorities that are indicated. These conclusions can be presented as Pareto Diagrams, or 
bar or pie charts to indicate the relative priorities of the customer needs and the tec hid cal 
solutions. Strategic and tactical plans can now be developed to implement the conclusions 
indicated by the QFD process. 

The House of Quality chart is described in detail in Appendix F. The actual composite 
House of Quality for the RPOC QFD process is in Appendix G. A chronological listing of the 
activities end the QFD process actually followed by the team is presented for reference in 
Appendix H. A list of QFD team observations is provided in Appendix I for consideration in 
similar futur ^ efforts. 




J. Yeo/JSC Navigation, Control, & Aeronautics Division (EG): Jody served as the 

facilitator. He is currently the Guidance, Navigation and Control (GN&C) System 
Development Manager (SDM) for the Space Station Freedom (SSF) Program. 


S. Lamkin/JSC Navigation, Control, & Aeronautics Division (EG): Steve served as the 
assistant facilitator as well as the recorder and editor of the documentation. He is the 
NASA Technical Manager for the NASA Headquarters Code R sponsored Autonomous 
Rendezvous and Docking (AR&D) project. 

W. Culpepper/JSC Tracking & Communications Division (EE): Bill provided expertise in 
the areas of sensor technology and hardware development. He supports multiple NASA 
programs. 

F. Elam/JSC Navigation, Control, & Aeronautics Division (EG): Frank provided expertise 
in the areas of systems integration and advanced test bed concepts. He is manager of the 
Advanced Avionics Laboratory, a derivative of the SSF GN&C Emulator Test Bed. 

P. Kachmar & S. Solis/C. S. Draper Labs: Peter and Sonny jointly represent CSDL in 
providiry Integrated GN&C System expertise to the team. They’ve supported various NASA 
projects since Apollo, and currently support the Space Shuttle (SS), Space Station Freedom 
(SSF) and the Space Exploration Initiative (SEI) Programs, aB well as the AR&D project. 

B. Wissinger/ McDonnell Douglas Space System Company (MDSSC): Brad is the manager 
of the Application and Analysis Support Contract (AASC) rendezvous, proximity operations 
and tether group supporting the SS and SSF programs. He is also the lead for a task to 
develop an automated rendezvous mission planning tool. 

F. Clark/Lockheed Engineering & Sciences Company (LESC): Fred is the lead engineer for 
the Engineering Support Contract (ESC) group which is currently supporting the AR&D 
task. He has provided tool development and analysis support to JSC for SS, SSF and 
advanced programs. 

R. Eick/TRW: Dick provides project management and systems engineering and integration 
support to the AR&D project. 

R. Memam/JSC Syste ms Engineering Division (ET): Bob is involved with tool development 
and analysis associated with the Mars rendezvous phase of the Space Exploration Initiative 
(SEI). He also supports rendezvous analyses for various NASA programs. 

R. Schaf/JSC Flight Design & Dynamics Division (DM): B"^ represented the Mission 
Operations technical community. He is currently performing analyses and trades 
associated with SS/SSF rendezvous activities. 

W. Jackson/ JSC Navigation, Control, & Aeronautics Division (EG): Bill has supported 
rendezvous analyses for all NASA programs. He is currently the Head of the On-orbit 
Guidance and Prox Ops Section. 

Individuals providing expertise to the QFD team on a part time basis were: 
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E. Jones/General Dynamics: RPOC 
N. Smith/Martin Marietta: RPOC 
B. Bicknell/Martin Marietta: QFD process consultant 
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Annendix B. RPQC Elements. Functions, ami Characteristics 

The following is the RPOC QFD team compilation of significant elements and functions 
that characterize rendezvous, proximity operations, and capture, or are necessary to 
effectively understand and work in this area. 


1 . 1 . 

1.2. 

1.3. 

1.4. 

1.5. 




2 . 1 . 

2 . 2 . 


3.1. 

3.2. 

3.3. 

3.4. 

3.5. 

3.6. 

3.7. 

3.8. 


4.1. 

4.2. 


4.3. 

4.4. 

4.5. 


4.6. 

&_ 

5.1. 


World-Wide RPQC Design Knowledge Capture 
World-wide RPOC Data Collection 
P n OC Community Directory 
oa Base Building 
Synthesis & Analysis 

Capture as Applicable from each Organization/Program 

Advanced Technology Development 

Technology Requirements Definition 

RPOC Technology Readiness Level 

Program Description & Planning 

Establish Need For RPOC 

Define Goals 

Safety 

Servicing 

Reliability 

Maintainability 

Cost 

RPOC Benefits Definition 

Misaion/Program Architecture Definition Studies 
Mission Design 
Mission Constraints 

4.2.1. Plume Impingement 

4.2.2. Collision Avoidance 

4.2.3. Out-of-plane Requirements 

4.2.4. Target Vehicle Characteristics 

4.2.4. 1. Cooperative 

4. 2. 4. 2. Uncooperative 
Conceptual Design 

Planning Methodology 
Profile Planning 

4.5.1. Attachment Planning 

4.5. 1.1. Tethering 

4.5. 1.2. Berthing 

4.5. 1.3. Docking 

4.5.2. Separation (Undocking) 

4.5.3. Rendezvous Profile 

4.5.3. 1. Long Range 

4. 5. 3. 2. Short Range 

4. 5. 3. 3. Orbit Characteristics 

4.5 Launch Windows 

4.5.5. Proximity Operations 

4.5.6. Formation Flying 

4.5.7. Stationkeeping 
Mission Design Products 

4.6.1. Design Reference Missions 

4.6.2. Error Budgets (Requirements) 

fiocaatiaas 

Pre-Mission Preparation 

5.1.1. Dispersions (Trajectory) 
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5.2. 


5.3 

6 . 1 . 


6 . 2 . 

6 . 2 . 1 . 


6 . 2 . 2 . 

7.1. 


7.2. 

7.3. 

7.4. 

7.5. 

7.6. 


8 . 1 . 


8.2. 


8.3. 

8.4. 

liL. 

11 ^ 


5.1.2. Contingency Definition 

5.1.3. Training 

5.T.4. F.-ocedures Development 

5.1.5. Rules Development (Systems Operating) 

5.1.6. Safety 
Real-Time Operations 

5.2.1. Ground Support 

5.2.2. Mission Control 

5.2.3. Sustaining Engineering 
Post-Mission Analysis/Documentation 
RPOC Analysis and Evaluation 
Methods/Tools 

6.1.1. Prototyping 

6.1.2. Simulation 

6. 1.2.1. Man-in-the-Loop Simulations 

6. 1.2.2. Non-Real Time Simulation 

6.1.3. Statistical 

6. 1.3.1. Monte Carlo Simulations 

6.1.4. Trajectory Dispersions 

C.1.5. Analytical Methods 

6.1.6. Test Beds 
RPOC Product Types 
Performance Analysis 

6.2. 1.1. IGN&C Performance 

6.2. 1.1.1. Sensor Evaluation 
Trade Studies 

6.2.2. 1. Command & Control Partitioning 

BffQC Operation 

Modes 

7.1.1. Autonomous 

7.1.2. Automatic 

7.1.3. Manual 

7.1.4. Teleoperated 
Proximity Operations 
Stationkeeping 
Formation Flying 
Rendezvous 
Attachments 

7.6.1. Berthing 

7.6.2. Docking 

7.6.3. Tethering 



Overall System Integration 

8.1.1. Performance Analysis 

8.1.2. Performance Envelope 
Integrated Test & Verification 

8.2.1. Ground Demonstration 

8.2.2. Flight Demonstration 
Configuration Control 

Test Facilities Requirements Definition 
Manufacturing' 


Project Management 
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11 Cost Control 

IS Documentation 

14 RPOT Integrated System Definition & Devekmmfint 

14.1. Integrated System Functional Requirements 

14.2. System Design, Development, Test & Evaluation (DDT&E) 

14.2.1. Data Management System 

14.2.2. Power 

14.2.3. Propulsion 

14.2.4. Integrated GN&C System Definition 

14.2.4.1. Guidance/Targeting 

14.2.4.2. Control 

14.2.4.3. Navigation 

14.2.5. Communications & Tracking 

14.2.5.1. Tracking Sensors 

14.2.6. FDIR/FDA (Fault Detection Isolation & Recovery /Fault Detection 
& Annunciation) 

14.2.6.1. Redundancy Management 

14.2.7. Mechanical 

14.3. System Architecture 

14.3.1. Distributed System 

14.3.2. Centralized Syscem 

14.4. Crew/Operator Interface 

14.5. System & Subsystem Integration 

14.6. Vehicle Considerations 

14.6.1. Vehicle Under Consideration 

14.6.2. Other Vehicles 


14.6.2.1. 

Consumables Constraints 

14.6.2.2. 

Sensors 

14.6.2.3. 

Propellant Capabilities 

34.6.2.4. 

Out-of-plane Capabilities 

14.6.2.5. 

Rotation-Translation Effector Capability 

14.6.2.6. 

Structural Characteristics 

14.6.2.7. 

Docking Contact Conditions 

14.6.2.8. 

Structural Constraints 


14.7. 

Hardware 



14.7.1. 

Sensors 


14.7 2. 

Docking Mechanisms 


14.7.3. 

Robotics 


14.7.4. 

Component Design 

14.8. 

Software 



14.8.1. 

Fuzzy Logic 


14.8.2. 

Artificial Intelligence 


14.8.3. 

Neural Networks 


14.8.4. 

Algorithms 


14.8.5. Hardware Interface Programs (HIPs) 
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Appendix C. List of Potential Customers 

Space Groups or Organizations 
National Space Council 
Space Studies Institute- 
National Space Society 
L5 Society 

Department Of Defense 

National Aerospace Plane (NASP) 

US Space Command 
On-Orbit Refueler 
Strategic Defense Initiative Office 
Defense Advanced Research Project Agency 
Naval Research Lab 
Space Systems Div (USAF/AFSC) 

Shuttle Pallet Satellite (SPAS) 

NASA 

Headquarters 

Code M - George Levin/Mike Card 
Code R - John Di Battista 
Strategic Avio^’cs Technology Working 

Group - Ken Cox, Chairman 

Goddard Space Flight Center- Technology 
Johnson Space Center 
Ames Research Center 
Langley Research Center 
Kennedy Space Center 
Lewis Research Center 
Jet Propulsion Lab 
Marshall Space Flight Center 
Stennis Space Center 

Uniy-firsitififl 
U of Alabama 
U of North Dakota 
U of Texas - Austin 

Foreign 
USSR 
Japan 

Orbital Servicing Vehicle (OSV) 

R-il Orbiting Plane (HOPE; 

European Space Agency (ESA) 

Hermes 

Man Tended Free-/ Iyer (MTFF) 

Space Eroloratioa Initiative (SEP 

JSC New Initiatives Office 

Technology & Commercial Projects Office 
Solar System Planet Rendezvous 
Lunar & Mars Exploration Projects Office 
Mars Rover/Sample Return (MRSR) 
Mars Observer 
Mars Transfer Vehicle 
Lunar Transfer Vehicle 
Comet & Asteroid Rendezvous/Flyby 


Planetary Surface Systems (PSS) 
Personnel Launch System (PLS) 

Lunar & Mars Exploration Program Office 
System Engineering & Integration Office 
liission Development & Operations 
Space Shuttle 

Shuttle Deputy Director - L. Nicholson 
Engineering Integration Office - L. Williams 
Integration & Operations Office - H. Lambert 
Flight Design - J.Harpold, M.Collins, E.Smith 
Laser Docking Sensor Flight Experiment - 
J. Prather 

Assembly Integration Panel 
Assembly Operations Engineering 
Assessment Panel 
Space Station Freedom 

Level 3 - JSC Mission Operations Directorate 
Assured Crew Return Vehicle Project Office 
Heavy Lift Launch Vehicle/Cargo Transfer 
Vehicle - MSFC Program Office 
Polar Orbiting Platform 
Orbital Maneuvering Vehicle (OMV) 

Satellite Servicing System 
GEO Repair. Service & Retrieval 
Artificial Satellites 
Deolovahle Stages 

Deployable 3rd Stage - IUS, PAM, Centaur, 
TranStage, Delta Star, Delta Zenith 
Tethers 

Tether Applications in Space W.G. - Code M 
Tether Satellite System Program Office 
Advanced Manned Launch System (AMLS) 
Contractors 

Honeywell International 
Litton 

Aerospace Corp. 

Hughes 

IBM 

COMSAT 
GE/RCA Aerospace 
Leral Corp 

McDonnell Douglas Space Systems Co. 

TRW 

Rockwell International 
Martin Marietta 
General Dynamics 
Lockheed Missiles & Space 
Boeing Aerospace 
Southwest Research Institute 
C.S.Draper Labs 
Orbital Sciences 

Environmental Research Institute of 
Michigan (ERIM) 


Cal Tech 
MIT 

Johns Hopkins U 
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Appendix D. The Customer Interview Process 

Interviewing customers to determine their needs is a key element of the QFD process. The 
team attempted to anticipate these needs, and get smart, in brainstorming sessions before 
the interviews began. The team prepared a question structure, based upon the RPOC 
characteristics and elements described in Appendix B, with specific questions to ask the 
customers. Before each interview, each interview team selected the questions that were 
most appropriate for the particular customer. Actually interviewing the customers and 
carefully noting their needs was critical to developing the House of Quality. Trying to rate 
the importance of various needs without input from the customers would be virtually 
impossible. The interview teams found this an easy task after hearing the customer’s 
concerns. 

To conduct the interviews, the RPOC QFD team was divided into teams of tnree persons 
each. (Additionally, a separate team went to Marshall Space Flight Center.) One 
individual in each team was selected as the primary interviewer, and one was selected as 
primary recorder. (Two teams also used a tape recorder.) All three members participated 
in the interview to varying degrees, but the primary interviewer was charged with asking 
the prepared questions, and keeping the interview on track if tangential issues arose. 

After the interviews were completed, each group made Affinity/Trees of individual 
customer’s needs, and ranked these in importance on a scale from 1 to 5 (5 being the most 
important). Any items mentioned by the customer that the team decided were not 
fundamental needs (“whats”) but rather technical solutions (“hows”) to other basic needs 
were carefully noted. Each group prepared a narrative of the interview. Any “whats” or 
“hows” mentioned in the interview were annotated in the narrative. This served two useful 
purposes: first, by carefully examining and understanding the narrative, the interview 
groups could double-check their work to make sure that no needs identified by the customer 
were missed; second, these narratives were returned to customers for review and 
clarification, and to show how their comments were used in development of the RPOC QFD 
House of Quality. Traceability between the RPOC QFD House of Quality and the narratives 
was maintained, and proved useful to both the customers and the te^m. 


* 


D-l 



JSC-25458 



Wi 


? 


\ -V 

*•* ■_ 

Appendix E. Definitions of Customer Needs and Technical Solutions 

The following definitions of customer needs and technical solutions were de /eloped within 
the RPOC QFD team for consistency and to establish a common base of understanding. 

They do not necessarily represent "official" or even complete definitions; instead they 
represent a level of completeness necessary for the RPOC QFD team members and 
customers to achieve a common understanding. 

I 


E-1 RPOC QFD Definitions of Customer Needs 
E-Ll System Operability 


i 


E.1-1-1 OnfimixP TWtpp of TndpnpnHpnre 

Optimizing the degree to which a system is free from external supervision or control enta 
choosing the level of independence most suitable for achieving mission goals consistent w. 
constraints. Examples of these levels are autonomous, automatic, supervised and manual. 

E- 1.1.2 Ease of Use 

A system is said to have ease of use if it has intuitive displays and controls. Ideally, an easy- 
to-use system requires minimal training because its ftmctions and modes are intuitive. 
Controls behave in predictable ways, and displays present information in a consistent 
manner. 


E;U*L Jge^YEJElimctiqaal Partitioning 

A design optimization process by which the functions required to perform an objective are 
analyzed and allocated for efficient resource utilization and maximum performance. The 
functions may be divided among hardware, software, onboard, earth based, other surfaces 
in space and systems. 

E-1J2 Me#ft Mission/Program Objectives 

E-1. 2.1 Unmanned Rftsunnlv 

The use of un mann ed spacecraft to deliver to or retrieve from another spacecraft items 
such as consumables, waste products, replacement equipment, and maintenance supplies. 

F- 1-2-2 Autonomous RPOC 

The capability of a vehicle s systems to evaluate and alter its operation to achieve 
rendezvous, perform proximity operations and effect a capture with another vehicle 
(cooperative or uncooperative) without external supervision or control. 

Fr 1.2,3 Tenhnimies 

The design of rendezvous profiles. This includes determination of targeting offsets 
(aimpoints) to minimize propellant usage subject to operational and guidance, navigation 
and control constraints. Consideration mus* be given to appropriate use of onboard 
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navigation, and its effect on controlling trajectory dispersions. Techniques must also 
contend with lighting constraints, timelines, and phasing. Appropriate targeting must be 
used. Techniques may include the capability to handle rendezvous in highly elliptical and 
hyperbolic orbits, multiple rendezvous, and rendezvous to a libration point in the earth- 
moon system. 

E-l.2-4 Efficient Proximity O perations Te ohnimies 

The development of control techniques used during proximity operations (see definition) 
which take into account sensor performance and result in efficient propellant usage, 
acceptable piloting/control workloads, minimum plume impingement and contamination 
effects, and efficient time usage while meeting required safety and consumables 
constraints. The development applies to techniques used during approach, stationkeeping, 
or departure activities between two or more spacecraft. 

E-lrg,5 Effective Space Traffic Control 

This function involves the concurrent ctive control of space vehicles (usually two or more) 
relative to a common reference. This reference may be an active vehicle or a non-active 
space base. This function is characterized by procedures such as formation flying, 
stationkeeping and collision avoidance. Key initiatives to meet this need include: (1) 
development of advanced sensors and algorithms; (2) definition of control strategy and 
operating zones; (3) simulations and (4) flight demonstrations. 

E-LS Low Program Risk 

E-l.3.1 Reliable Systems 

Reliable systems assure that critical functions are supported with a high probability of 
success over the required lifetime by utilizing various system design techniques. These 
techniques may include using: simple, inherently reliable hardware (i.e. hardware with 
high Mean Time Between Failure); or redundant hardware components with the 
appropriate failure detection, isolation and reconfiguration schemes implemented; or 
redundant information derived from dissimilar sources; or use of conservative design 
margins which allow higher levels of sensor or effector error (thus reducing the likelihood 
of a critical hardware failure). Reliable systems support low program risk. 

E- 1.3.2 Demonstrated Systems & Technology 

Having demonstrated systems and technology implies that a given technology has actually 
been demonstrated before it has to be used by a particular program. This approach lowers 
program risk, because a program manager does not have to develop unproven technology. 
The word “demonstrated” in this definition is essentially a synonym for “proven”. Note that 
the terminology “demonstrated” technology is in past tense. The program manager does not 
want to be responsible for trying out the demonstration. 

E- 1.3.3 System Acceptability 

Ideally, 83'stem acceptability is the process by which a system is compared tc an accepted 
standard and deemed functionally equal to or superior to that standard. In this process, the 
standard is defined by the appropriate members of the RPOC community. The baseline 
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system becomes certified when it meets the standard. Then, an additional system would be 
acceptable if it meets or exceeds the standards of the certified system. 

In practice, such an absolute standard may be impossible to define, a priori. More likely, 
the standard will evolve over time. Given this, system acceptability is somewhat subjective. 
However, it certainly is enhanced by using demonstrated technology, reliable systems, and 
a conservative design philosophy; in other words, anything that would make a system more 
acceptable in the common sense of the word. 

E-1.4 Low Programmatic Cost 

E-l.4.1 Increase Design Process Efficiency 

This function increases the productivity of engineers defining and designing new onboard 
or ground systems. The design process includes requirements definition and validation, 
system engineering and integration, requirements integration, and product hardware and 
software design. Examples of improvements include using engineering work stations with 
advanced three-dimensional graphics, improved data bases, automatic software code 
generation, and the use of interactive design groups in a concurrent engineering process. 

E-l.4.2 Accommodate Technology Growth & Insertion 

Accommodate technology growth and insertion means to do those things, both during the 
original design and manufacture, and during the operational phase, which will facilitate 
subsequent technology advancement of onboard and ground hardware and software. 
Examples include the use of system modularity, effective hardware/software partitioning, 
standard interfaces, and hooks for increased automation. 

E-L4.3 Increase Operations Efficiency 

This refers to efforts to reduce the overall resources required (or cost) to accomplish the 
mission objectives of the program during the Operations Phase (or Phase D), It includes as 
subheadings; 

a. Creating a Mission & Operations Concept which is most cost effective: Laying out a 
scheme for conduct of missions which trades off cost (or resources required) against setting 
up an operations organization which is required to perform the mission(s) envisioned by 
the program. 

b. Reduce cost controllable items in the operations effort: This is an effort to 
streamline the operations effort without reducing the real-time operations. This includes 
reducing the replanning and mission preparation required between missions, post flight 
reconfiguration for the next flight, facilities costs between missions and the man hours 
used in these functions. 

c. Include operations consideration in the definition and design phases of the 
program. 

E-1.5. Knowledgeable Comprehensive Consultation 

This refers to the need that the customer has for consultation concerning all phases of 
RPOC. The consulting organization should possess, or have ready access to, information on 
hardware and software; functions of guidance, navigation, control, sensors, structures, 
propulsion, power, vehicle health monitoung, and expert systems; pertinent work being 
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accomplished in government and industry; facilities and support capabilities available; 
interrelationship and application of Code R focused technology, Code M advanced 
development, and specific vehicle needs with consideration of multi-programs. Particular 
customer needs include: 

a. Support for funding advocacy: The data and information would be provided to 
program and project managers, advanced activity planners and budgetary officials <o assist 
them with determining needs, direction, rationale, relative importance of past, present and 
future tasks and capabilities in the rendezvous, proximity operations and capture 
community. 

b. Timeline of Programmatic needs: Refers to the need for program and technology 
funding organizations and managers to lay out funding levels and schedules for each fiscal 
year so that projections for future programs can be constructed. 

c. Technical Advice: Refers to the wide area of expert advice needed by customers for 
direction and decision making. 

d. Trades/Simulations/Studies: Refers to the customer need for trade studies, 
simulations and/or testing during the development of programs or systems, and where to 
go to contract for such services. 

E-2 RPOC QFD Definitions of Technical Solutions 


E-2.1 DESIGN PHILOSOPHY ■ 

j; 

EALI ..Use Incrementflllteagai Approach 1 

The philosophy of increasing m conservative intervals from a basic design toward an 
enhanced design that meets the system's total objective(s). It implies verification of the ) 

current design level before proceeding to the next increment and tends to phase in the j 

utilization of new systems designs and concepts to lessen the chances of failure. It is also i 


concerned with dela 3 ri ng the incorporation of new technology into designs until that 
technology is sufficiently mature and demonstrated to limit the level of ri ik. 

E-2. 1.2 Use Simple Systems 

The concept of utilizing systems and designs that have been developed at the lowest level of 
complexity necessary to accomplish a task. The multiple use of identical components 
within a subsystem, subsystem elements within a system, or software modules within a 
software system can also contribute to the sense of having a simple system. 

E-2.1.3 Use Failure Resistant Components 

The philosophy of using the most reliable components and parts available and/or affordable 
to increase the reliability of the entire system. 

E-2,1,4 Use Redundant Components & Information 

The application of the same component or subsystem in parallel one or more times in an 
effort to offset the impact of failure of a single component or subsystem. Redundant 
information can be derived from dissimilar sources and used in the same manner. The use 
of redundancy implies the need for a managing criteria to handle failures by selecting an 
alternate path within the parallel environment in the event of a failure. 





E-2.1.5 Use Conservative Margins 


A system design is usually based on a set of nominal parameters. The design is expected to 
continue to function should any one or more of the parameters be somewhat off nominal. 
The ability to function with this off-nominal condition mears that the system has margin. 
If the system can be designed to remain functional even if some (not necessarily all) 
parameters or sets of parameters tehe on values beyond what might be expected, that 
system can be said to have been designed with conservative margins. Alternatively, the 
system might be said to be robust. 

E-2.1.6 TTfift Standard* /fid Interfaces 

An interface is a process that allows system building blocks (hardware and software) to be 
connected. A standard interface means that all building blocks (of a certain category) have 
the same interface and hence their interconnects s are uniformly defined. The use of 
standardized ' Herfaces within a system design is a positive influence in areas such as ease 
of design, cos. of design, time to complete fabrication, cost of procurement, and ease of test 
and checkout. Standardized interfaces also provide a simple, predictable means of 
inserting technology at a later date. As examples, standard interfaces can apply tc 
electrical power, signal, mechanical, thermal connections and software modules. 

E-2.1.7 Use Friendly Interfaces 

The employment of connections (visual, audible and tactile) between the system and 
humans that are comfortable, consistent, easy to use and intuitive to the human. This 
approach enhances operation of the system. 

E-2,1,8 Define System s Requirements for Minimum Training 

The process, generally early in a program's development, where the system partitioning 
and degrees of autonomy are established with emphasis given to diminish the amount of 
human intervention and participation required in the operations phase of the task. 

E-2.1.9 Use Concurrent Engineering Process 

Concurrent Engineering refers to the simultaneous application of three elements 
(management processes, quality function deployment processes, and quality engineering 
for "robust" design) to reduce product development costs, increase customer satisfaction 
with the products, and reduce the product development time. 

Management processes include four points to develop a better "game plan" and three points 
to eft*., c doser cooperation: 

Better "game plan" 

a) Concurrent processes (production capability, field support capability, and robust 
quality) 

b) Focus activities on quality, cost, and delivery 

c) Emphasise satisfaction as perceived by the customer 

d) Emphasize competitive benchmarking 
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a) Integration of the organization 

b) Employee involvement and participative management 

c) Strategic relationship with suppliers 

Quality function deployment (QFD) processes ensure that the "voice of the customer" is 
present from the very start of the product development process. 

Quality engineering for "robust" design refers to the ability of the product to keep 
performance close to ideal customer satisfaction under actual use conditions. It redu'- js 
rework of the design due to operating conditions or production methods, because "quality is 
developed concurrently with the product design and the development of production and field 
support capability". 

[Ref: Clausing, D., Concurrent Engineering . Design and Productivity International 
Conference, Honolulu, Hawaii, 6 February 1991.] 

E-2.2 Collect & Exchange Knowledge 

£-2,2,1 Perform Survey of State-of-the-Art RPOC Capabilities 

The act of performing a survey (literature searches, government and industry surveys, etc.) 
to define the state of the art of hardware, software, systems and facilities associated with 
the RPOC functions and the compilation of collected data. 

E-2.2.2 Build Databases 

The process of defining and implementing database structures to effectively capture and 
track the characteristics, capabilities and level of maturity of RPOC related technology 
(hardware, software, systems and facilities) and the subsequent data entry and database 
maintenance. 

E-2&3 Develop Integrated Technology Plan 

Identify requirements (needs and timeframe) for technology/advanced development 
activities. Develop and advocate a plan to develop and demonstrate the technology required 
to meet the identified system needs within the desired timeframe. Review and update the 
plan annually. 

E-23 Develop Advanced Technology 
E-2.3.1 Devdon Advanced Sensors 

Develop the advanced technology required in the senscrE area to meet identified system 
needs by a specified date. The technology development should be evolutionary and 
applicable to multiple programs, if possible. The development should provide for the 
lushest possible technology readiness level prior to system incorporation. 

E-2.3.2 Develop Advanced Algorithms 

Develop the advanced technology required in the area of software algorithms to meet 
identified system needs by a specified date. The technology development should be 
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evolutionary and applicable to multiple programs, if possible. The development should 
provide for the highest possible technology readiness level prior to system incorporation. 

DfivPinp Imnrovpd Dorking M^ianisms & Fnralities 

Develop the advanced technology required in the area of docking mechanisms to meet 
identified system needs (e.g., reliability) by a specified date. The technology development 
should be evolutionary and applicable U multiple programs, if possible. The development 
should provide for the highest possible technology readiness level prior to system 
incorporation. Hardware evaluation facilities should contain new docking mechanism 
concepts. Hardware evaluations should include malfunctions such as damage, 
degradation and debris fouling (e.g., insulation). 

E-2.4 Define Mission Architectures, Requirements & Constraints 

E-2.4.1 Develop Resupply / Return Mission Requirements 

Define the factors affecting the rendezvous, proximity operations, and capture (RPOC) - 
related design of resupply missions to an orbiting vehicle or scientific facility, such as 
types/amounts/characteristics of transported items, resupply frequency, characteristics of 
the vehicle being resupplied, and trajectory data. 

E-2.4.2 Devplon Traffic Control Strategy 

Define the methods and techniques required to control the orderly and safe movement of 
spacecraft within a predefined volume around an orbiting vehicle. The strategy should 
minimize the operational complexity and probability of collisions. 

E-&4.3 Csfinp PpfrTfttmg Atoms 

Based on mission objectives, vehicle constraints, and the traffic control strategy, define the 
regions of space in which a vehicle may or must operate relative to a base vehicle. The 
zones are delineated by the allow&Ole operations within the zone. 

E-2.4.4 TlpfinP Onprutinf Modra 

Establish the methods by which a spacecraft will accomplish its functions during specific 
phases in its mission with respect to the level of autonomy. Basic modes are autonomous, 
automatic, supervised, and manual. 

E-2-6 Define System Requirements 

F-2-K-1 Ifariv Definition & Maturity of Requirements 

Apply adequate resources and effort at the very beginning of a project to thoroughly perform 
the trade Btudies and simulations to yield realistic program and system requirements that 
minimize later revision. A requirement is a specification of some aspect of a deliverable 
end-item. The term requirement connotes that which is a must, the irreducible minimum 
of acceptability, an imperative, as contrasted to the merely desirable or merely an objective. 
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A requirement at the more general level defines a function to be performed, not how to do it. 
Such requirements are used at Level I as broad program obj r tiros, and in Level ii for 
system functions. Level II also contains environment, reliability, lifetime, verification, and 
project timelines. Level III contains detailed systems requirements, including functional 
decomposition, performance specifications, and interfaces. 

Early definition and maturity of requirements will greatly increase the design process 
efficiency and thus lower the programmatic costs. 

Improve System Etequireareats IYareabilitvI’rflgaas 

There are two purposes for requirements traceability. One is to maintain a bidirectional 
bookkeeping process that shows the documentation source of a detailed requirement based 
cn a more general requirement. This is a dry, bare-bones numerical cross-referencing 
system without explaining the rational or derivation of the more detailed requirement. The 
second aspect of reouirements traceability, equally important, is to document the rationale 
of the derived requirement as contained in a trade study, analysis, simulation, or other 
report. 

Without two-way traceability, a requirement may be overlooked (going from the general to 
the specific), or a detailed requirement may not be updated when a change is made to the 
parent requirement. Without documentation of the rationale or analysis of a numerical 
specification, it will be unknown and unchallengeable as to what degree of confidence the 
original author of the performance specification intended to convey, whether the analysis 
has become obsolete, or whether it contains errors. 

E-2.6 Define Operating Requirements 

E&fLl Epaada Effective Tekmetry/C^mmtm^Ng^igatiQa ipfcastocfaiis 

This infrastructure consists of the collection of telemetry, command and navigation links 
and the facilities which control, generate or receive them. The support i) provides to an 
operational RPOC vehicle is effective if the RPOC mission objectives are satisfied while 
providing adequate capability for command, control and monitoring at the same time. The 
infrastructure may have to (for example) support various levels of independence, require 
minimum/acceptable vehicle reconfiguration and provide adequate communications 
coverage and reliability, 

E&&2 Mis^aon Deneratent Reconfiguration 

This item refers to the efforts to minimize the reconfiguration of reusable vehicles and 
systems to meet the mission peculiar requirements of the next flight. Such reconfiguration 
is a necessary cost burden but cp" be controlled and/or standardized where possible. Also 
included in this item is reconfiguration of facilities (Mission Control Center (MCC), 
communications & tracking network, etc.) if called for in the mission requirements. 
Considerations of reconfiguration costs should be embedded in the design process for future 
RPOC vehicles. The acceptability, reliability and ease of use of reusable RPOC 
systems/vehicles will be enhanced by diligence in this area which, in a wider sense, is 
aimed at reducing or controlling the cost of operations. 

List of Mission Dependent Reconfiguration Items: 
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Mission Planning: 

Payload Rules Development & Publication 
Timeline Development & Publication 
Procedures Development & Publica. 

Flight Design Development & Public*. .ion 
All mission verification 

Reconfiguration of Mission Dependent Hardware Interfaces 
Reconfiguration of Mission Dependent Software 
MCC/LCC Mission Dependent Reconfiguration 
Team/Crew Training (includes facilities time) 

Interface Testing 

Payload Mounting/Servicing Pre-launch 


E.-2A2. JBeducsfijaadacdizB Flight So 
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? Reconfiguration 


This item refers to the efforts to minimize the periodic software reconfiguration for 
reusable vehicles and systems to satisfy the changed requirements which normally burden 
flight software loads. This is a necessary configuration control task. However, measures 
are needed to accommodate the upgrading and redesign of flight software so as to reduce 
the manpower and facility time required. This wall be especially important as vehicle, 
system, and ground software increases in volume and complexity with the advent of expert 
systems, autonomous systems and more capable on-board algorithms. In such an 
environment, an inefficient and expensive reconfiguration process wall reflect on system 
acceptability, reliability and ease of use. Accommodation of software recoringuration 
should be considered early in the system design and continue throughout the design 
process. Although the primary aim of this effort is to control the overall cost of operations, a 
wider impact is realized. 


K-2.6.4 Reduee/Standardize Flight Turnaround Reconfiguration 

This item refers to the effort to minimize the non-mission dependent reconfiguration 
which is required to prepare a reusable vehicle or system for the next flight. Such 
reconfiguration or turnaround activities include inspection, testing, repair, transport, re- 
outfitting and refueling of the reusable RPOC vehicle or system. Also included are any 
ground facilities which require turnaround reconfiguration. Complex and costly 
turnaround requirements will affect the acceptability, reliability and ease of use of the 
vehicle/system. Turnaround considerations should enter into the early design process and 
continue during mission scheduling and launch processing. The aim is to reduce the cost 
of operations, but impacts in many other areas are evident. 


List of Turnaround Reconfiguration Items: 

Generic Mission Planning: 

Generic Rulus Maintenance 
Generic Procedures Maintenance 
Generic Flight Design 
Generic Timeline Maintenance 
All Revtriucation 

Repair/Outfitting/Upgrades Processing at Landing Site/Launch Site 
Transportation to Launch Site 
Facilities Maintenance 
MCC/LCC/Landing/Abort. Site Turnaround 
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All Generic Training 
E-2.7 Design RPOC Systems 

E-2.7.1 Perform Functional Analysis on »]] RPOC Systems 

An iterative process by which system functions and sub-functions are progressively 
identified and analyzed as a basis for defining alt. natives for meeting system performance 
and design requirements. Performance requirements are established for each function and 
sub-function identified. System functions include mission, production, test and support 
functions. All modes of operational usage and support are considered in the analysis. (See 
MIL-STD-499A) 

E-2,7.2 Develop Trajectory App roach Techniques 

As used here, “approach” is regarded as the final approach to a target. Approach generally 
corresponds to the region in which proximity operations occurs. Considerations include: 
propellant consumption, plume impingement and contamination, lighting, relative 
attitude, and safety. 

E-2.7.3 AdpIv Expert Systems to RPOC 

The development of rule-based software technology applications to support the system 
functions required to perform the Rendezvous, Proximity Operations and Capture mission 
phases. 

fi-2,7,4 PfiYstoo. Algorithms for iteracterrims 

These algorithms include any guidance and targeting that are needed for rendezvous. 
Different algorithms are needed for rendezvous in low earth orbit, rendezvous in elliptic, or 
hyperbolic orbits, or rendezvous to a libration point. Other critical algorithms include 
various types of estimation needed for state determination. Expert systems are not 
considered to be a part of this category. 

E-2.7.5 Develop Attitude & Translational Control System? tn Minimise Plum* 
Impingement & Contamination 

This may include propulsion systems that use inert gases. In this case, plume may still be 
a problem in terms of loads, but contamination problems are greatly ameliorated. Systems 
for attitude control include momentum wheels, control moment gyros, and other non- 
propulsive systems. Minimizing plume impingement and contamination is of major 
concern only during proximity operations. 


E*2i5 Evaluate RPOC Systems & Technologies 

E-2.8.1 Perform Systems & Technologies Trade studies 

This item uses the term "trade study" in a limited sense, as defined below: 

An analysis of competing alternatives performed to support decision making is 
called a "trade study" (or simply "trade"). The criterion for choosing the best alternative is 
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often cost or performance or a set of quantities which support a comparison. (Although 
analysis is net the only method of producing a quantifiable scale for comparison of 
alternatives, for the purposes of this QFD, only those trades supported by analysis are 
included in this definition. Trades supported by other means are included along with the 
other types of evaluations classed by the tool used, such as "simulations’ 7 , "hardware test" 
or "prototyping".) 

E-2.8.2 Perform Simula tioas • Non-Real Tune 

A simulation is an analysis tool conducted with a computer (or computers), containing 
math models of part or all of a flight system, together with math models of related systems, 
the flight vehicle (or vehicles), the appropriate vehicle dynamics and operating 
environments. Typically, time histories of variables are computed. As used in this report, a 
simulation does not contain actual system hardware, except for hand controllers or 
displays necessary for the man/machine interface. A simulation study often compares 
alternatives, whose results can be used for comparison. 

A non-real time simulation is one where the simulated time in the math model dees not 
coincide with time in the real world. This type of simulation does not contain a man "in- 
the-loop’. 

'-S.8.2 Perform Simulations -iteal Time 

A real time simulation is one in which the simulated time coincides with real time. This 
type of simulation can have a man ”in-the-loop" to judge human factors related to man- 
machine interfaces. Typical simulation configurations may contain realistic controls and 
displays, out- the -window scene generators, and cockpit mockups. As stated above, as used 
in this report, a simulation does not contain other system hardware. (See Section E-2.8.4) 

E-2.8.4 Perform Hardware Evaluations 

A hardware evaluation is a test of part or all of the RPOC and related systems’ hardware. 
It includes tests where the remainder of the system is modeled by a computer (or 
computers) similar to a "real-time simulation" as defined above. Hardware evaluation can 
be a limited physical test of a device or component, or combinations thereof. The hardware 
can be at any stage of development, such as engineering models, prototype hardware, flight 
quality hardware, or merely similar hardware. 

A hardware evaluation differs from a prototype or flight hardware demonstration in that 
the former is done in the earlier design stages of a project for the purpose of evaluation, and 
the latter is done later in the project, with the final design, as proof of satisfying the 
specifications. A hardware evaluation is designed to prove that the hardware meets the 
performance specificatic: . while a hardware demonstration merely shows that it works, 
somewhere within limit specifications. 

E-2.8.5 Perform Statistical Anflivsp.s 

These analyses utilize statistical distributions to represent vehicle or system performance. 
Performance is determined by various acceptable methods for sampling, averaging or 
calculating means and deviations at the times data are desired. Other methods (e.g. Monte 
Carlo, Covariance) interpret the statistical performance distribution as an envelope for 
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vehicle performance, and the statistical means and variances to forecast utilization 
figures, lifetimes, mean time between failures or ether desired quantities. 

E-2.8.6 Perform Rapid Prototyping & Te^ng 

Rapid prototyping is a process for quickly developing and testing designs satisfying a 
portion of the system requirements. It provides a basis for requirements verification, 
design concept vp 1: dation, and the final design specifications. Rapid prototyping is 
characterized by quick implementation and testing, frequent revisions, math modeling, 
and simulations. 

E-2.9 Develop & Maintain Co mm on Tools & Facilities 

E-2.9.1 Automate Design Process of KPOC System s 

Develop an efficient process to accomplish system design and validation (requirements, 
concept, development). The process should be characterized by: (1) effective, efficient tools 
(i.e., user friendly, graphics workstations which support multiple programs/functions and 
use a common database); (2) design knowledge capture (to maintain cognizance of state of 
art, technology/advanced development activities and sources. 1 ; and (3) improved study 
methodology (i.e., hands-on, quick turnaround, initially low fidelity with generic modeling, 
then higher fidelity as programs mature and data becomes available). 

E-2.9.2 Use Automatic Code Generation 

Use a tool which will accept the definition of software requirements in the form of logic 
flows, mathematical expressions, module delimiters, data flow diagrams, etc. and will 
produce executable software code in a form understandable by the developers of the 
requirements. It should include automatic documentation as a feature. 

E-2.9.3 Automate Mission Planning (Ground) & Replanning (On-board) 

Develop a tool which will accept mission constraints (lighting, phasing, sensor capability, 
fuel/time optimality, expected dispersions/uncertainties, etc.) and will generate candidate 
mission plans (trajectory, timeline, resource requirements, maneuver placement, etc.). 
The plans should be presented a "user-friendly" manner such that quick assessment 
and modification can be made miu che process repeated if required. The tool should be "end- 
to-end" such that multiple tools and data exchanges are not required. 

E-2.10 Demonstrate EPOC Jys terns & Capabilities 

E-2.10.1 Conduct Shu ttle Fight Demonstrations 

Use the Shuttle as an orbiting test bed for evaluation of RPOC related software, hardware, 
procedures, or techniques. Such demonstrations are needed to accommodate new RPOC 
technology or to prove new components or concepts necessary for ongoing or new 
programs. 


E»2.10J2 Cend ant Unmanned Vehicle Flight Demons 
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Use an unmanned spacecraft as an orbiting test bed for evaluation of RPOC related 
software, hardware, procedures, or techniques. Such demonstrations may be needed to 
accommodate new RPOC technology or to prove new components or concepts necessary for 
ongoing or new programs. 

E-2.10.3 Conduct Multi-vehicle Flight Demonstrations 

Use of multiple spacecraft simultaneously in orbit as testbeds for evaluation of RPOC 
related software, hardware, procedures, or techniques. Such demonstrations may be 
needed to accommodate new RPOC technology or to prove new components or concepts 
necessary for ongoing or new programs. 

E- 2. 10,4 Conduct Prototype System Ground Tests 

Conduct tests on the ground (as contrasted to in-flight test) of the complete RPOC system, 
using system hardware which is an early version of flight-quality hardware. Related 
systems (especially avionics) may also be included in the test, as either simulated or real 
hardware. The term includes both open loop and closed loop tests, The system is typically 
connected to computers providing appropriate interfaces, and math models similar to the 
simulations described above. System stimuli, environment, and output may be provided or 
measured by physical test equipment intended to closely approximate in-flight conditions. 

E-2.10,5 Conduct Ground Tests With Flight Hardware 

Means the same as the preceding definition, except that flight-quality hardware is used. 
Usually extreme measures are taken to control and certify precisely the test conditions, test 
data, anomalies, and other occurrences. These tests include functional tests, performance 
tests, acceptance tests, and official qualification test for the hardware and system. 
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Aapflidto. Ei— Ufluaa gf Quality Chart 

The House of Quality Chart, Figure E-l, is a working spreadsheet which shows the 
relationships between customer needs and the technical solutions resulting from the 
Quality Function Deployment process. The elements of the House of Quality, labeled on the 
referenced figure, are described as follows: 

1 Customer Needs This is a list of the customer needs, also called "Whats", demands, or 
needs. These customer needs are presented at a high level because this was a first phase 
QFD. The QFD identified fourteen level 2 and one level one customer needs. These reflect 
the expressed desires of the customers, as recorded in the customer interviews. 

2 Technical Solutions This is a list of the technical solutions, also called "Hows", which 
identify how the customer needs are to be satisfied. The Hows were taken from the second 
level of the tree diagram of technical solutions. There were forty-four Hows identified in 
this study. These were generally identified by the QFD team, not the customers. However, if 
a customer's response contained a How, it was included, and if no corresponding What 
was stated, a suitable customer need was inferred by the QFD team, and added to the list. 

3 Relationship Matrix Between Whats and Hows A score was recorded on the House of 
Quality matrix, indicating the degree to which each How would satisfy a customer's Need. 
Some of the Hows satisfy more that one What, and each What was supported by more than 
one How. The scores are a judgement by the QFD team, based upon their experience and 
knowledge. To distinguish the most important relationships, the scores were Strong 
satisfaction (9 points), Moderate satisfaction (3 points), Weak satisfaction (1 point), and No 
satisfaction (0 points). 

4 Correlation Matrix for Each Pair of Hows This matrix resembles the Roof of a house, 
which gives rise to the name of the House of Quality. Since many of the technical solutions 
are interdependent, each How supports or negates each of the other Hows to some degree. 
For example, redundancy tends to negate simplicity. The grades corresponded to two levels 
of positive and two levels of negative correlation, as well as no correlation. These 
relationships were evaluated and determined by the QFD team members, not the 
customers. 

6 Customer Names This element is a listing of the names of those customers who were 
interviewed. To preserve customer confidentiality, names are not specifically associated 
with the study results. 

6 Matrix of Priorities Each What is given a priority rating for each customer, from 1 to 5, 
with 5 being the highest. The Hows are not ranked by priority at this stage; their priorities 
are derived subsequently from a formula which includes the What priorities. These 
priorities were concerned not with importance per se, but with which What should be 
worked in the future, due to a present deficiency. For example, most customers would 
rank reliability as tops in importance; but if reliability were perceived as presently being 
adequate, it might rate a low ranking as to priority of future effort. The priorities are not 
exclusive; several Whats could be given the same priority rating. 

7 Weighted Rate of Importance This H the weighted average for each customer need for all 
customers. This rating is used in the later formula as the symbol "A". 
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8 NASA/Industry Achievement Ratings On a scale of 1 to 5, NASA and industry are rated 
by the QFD team on their combined degree of achieving each What, with 5 being the highest 
rating. One rating is given for the present, or "now", and one rating for the target 
achievement at the end of a period of time. The numerical ratio of the two ratings is a 
measure of the degree of improvement targeted during the project term. This ratio, 
designated as "D", was used subsequently in one of the formulae. 

9 Sales Point This item makes a What more important if, in addition to its own function for 
the RPOC product, its technology can be used in other products or systems. This rating was 
a judgement by the QFD team based upon their own experience, and not based upon the 
customer interviews. The allowable ratings were 1, 1.2 and 1.5. This rating is symbolized as 
"E" in the formulae. 

10 Importance Weight of Customer Needs The absolute weight for each What was obtained 
by the formula shown in Figure F-l (F = A x D x E), where the variables have been 
defined above. 

11 Relative Weight of Customer Needs The relative weight is the absolute weight, divided by 
the sum of the weights, expressed as a percentage. This is the final, significant rating of 
importance for each What, weighted by the several considerations 

12 Importance Weight of Technical Solutions The matrix ranking of each How with each 
What was adjusted, by multiplying each element in the matrix by the final importance 
weight of the related What. The resultant column for each How was then summed to obtain 
the importance weight for that How. 

13 Relative Weight of Technical Solutions The relative weight of each technical solution, or 
How, was divided by the total weight of all Hows, and converted to a percentage, to obtain 
the relative importance rating for each Ho \ 

14 Quantitative Target of Each Technical Solution Improvement is difficult to measure 
unless it can be done quantitatively. For each How, a ’-■unerical method of measuring the 
accomplishment of a How was determined. The House of Quality shows the unit of 
measurement, and the numerical target of each How for the project time period. The RPOC 
House of Quality in Appendix G does not show this information because of the numerous 
targets possible with the RPOC technical solutions; the list was too extensive to fit onto the 
chart. However, the RPOC QFD team did identify possible quantitative values of the 
technical solutions by identifying the methods, measurements, and values, where known. 
The results of this exercise are shown in Appendix J. 

15 RPOC QFD House of Quality The actual composite House of Quality for the RPOC QFD 
process is in Appendix G. The chart reflects the details of the highly structured analysis 
approach that is the heart of the QFD process, and the results of the team's activities. 
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Appendix G . The KPOC QFD House of Quality 
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AwnenrHx H. OFD Procftaa Artnnllv 

The sequence of events for the RFOC QFD was as follows: 

3/5/91 • •'fined the general objectives for this QFD process. 

* Obtained authorization and assurance of support from a suitable management 
sponsor. 

* Made arrangements for a consultant to provide QFD training and periodic support. 

* Made arrangements for team support from industry representatives involved the 
RPOC arena. 

* Selected the organizations needed to be represented. 

* Wrote sponsors letter to supporting organizations. 

* Assigned a facilitator and assistant facilitator. 

* Obtained organizational assignments of team members. 

* Made arrangements for a dedicated area to conduct the QFD for the planned period. 

* Established a tentative schedule and defined a statement of benefits. 

3/21/91 • Had a kick-off meeting of the team members with an introduction by the 

management sponsor. 

* Initiated the QFD training and used the consultant to help with the first few steps in 
the process. 

3/25/91 • Worked cut a definitive QFD objective that everyone bought into. 

3/25/91 * Brainstormed to define a list of potential customers. 

* Worked with management sponsor to pare the customer list to a manageable size of 
customers to be interviewed. 

* Define a potential product list off-line. 

* Brainstormed to define the RPOC functions and elements which are and need to be 
accomplished in the normal course of a program. 

* Developed a list of RPOC related terms which must be defined. 

* Worked as a total team to establish these definitions. This turned out to be very tedious 
and time consuming. 

4/4/91 * Brainstormed to define a What Tree based on speculation about what the potential 
customer needed. This proved to be very difficult to accomplish because we were unsure 
about what the customer really needed. We were also in a quandary about how to handle 
the wide disparity among potential customers and how to satisfy them all. 

4/5/91 • Brainstormed to define a complete list of questions to be asked of the customers. 

* Div' ’ed into sub- teams and made customer assignments to those sub-teams. 

4/8/91 • The individual sub- teams defined the specific questions to be pursued with each 
assigned customer. 

* A letter was written to the customers and sent by the management sponsor which 
defined in general the information being sought. 

* The sponsoring management staff set up the customer interview appointments. 

4/9/91 4 Used in-house "Practice Customers" with some insight into the real customer 

needs to start the interview process. 

* Established a standard interview product package to be generated by the sub-teams. 
This consisted of the following: 

• Customer What Tree with ratings 

• Customer interview narrative report which was reviewed by the customer and 
verified with major areas highlighted 

• Annotation of the customer narrative to show traceability of the needs to the 
resulting Whats and Hows in 1 the House of Quality Matrix. 
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4/29/91 • Brains tom :d with the whole group to define a final What Affini ty/Tree which 
meets the needs of all the customers. In some cases, we decided that what the customer 
stated as a need (What) was determined by the team to be a How and was assigned as 
such. 

4/16/91 • Brainstormed to define a How Affinity-Tree so that each What had one or more 
Hows which addressed it. 

• Made another round of sub-team customer interview assignments with a schedule 
established. 

4/22/91 • Conducted the second round of customer interviews, some of which required 
travel. 

4/29/9 1 • Revisited the What and How Trees to insure that the needs of all our customer 
were reflected. 

5/2/91 • Assigned sub-team responsibility for the definition of each What and How in the 
House of Quality Matrix. These sub-team6 produced a definition for each one and 
presented it to the total group for discussion and modification. Finally individuals 
within these sub-teams were assigned continuing ownership responsibility so that any 
further amplification or modification of these definitions would be documented. 

4/17/91 • Brainstormed with the whole group to score the relationship of the Whats and 
Hows. We did this in some cases with the whole team and in some cases with sub-teams 
which brought them back to the whole team for review 

4/25/91 • Decided to use a single composite weight of the customer needs for use in the 
House of Quality Matrix. This composite need weight was an average of the weights 
based on individual customer interviews. 

5/13/91 • brainstormed to define how well we were currently meeting the customers needs. 

5/13/91 • Brainstormed to define how well we should meet the customer needs by end of 
FY95. 

5/14/91 • Brainstormed to define which of the Whats were major and minor Sales Points. 

• Calculated the importance weights, relative weights of the Whats and resultant 
importance weights of the Hows. 

5/16/91 • Barbara Bicknell and Nick Smith of Martin Marietta developed some examples of 
how to quantify and arrive at target values for the Hows. Nick returned and discussed 
this process with us. We then assigned the responsibilities for this to the owner’s of the 
How definitions. After completion, these items were presented, discussed and modified 
as necessary. It was decided that the quantification parameters were more significant 
than the actual target values because actual measurement of the parameters may be 
difficult and expensive to implement. 

5/17/91 • Defined the correlation between Hows by assigning columns of the matrix to 
teams of two or three people to be worked in an afternoon. These values were later 
checked for agreement by another team. Any disagreement was brought before the total 
group for discussion and consensus. 

• We attempted to address the first objective for a near-term plan in a brainstorming 
session. We looked at tb righest priority Hows from the Pareto diagram (Figure 3) and 
noted that flight demonstrations of the hardware and a total system were very important 
Hows. We agreed that this was an area that had a good potential for successful near- 
term activities. We formed an Affinity/Trse of possible flight (or even ground) 
experiments which would meet tire customers needs. 

5/21/91 • In a group discussion, we listed a number of RPOC Issues (which in some cases 
may simply become actions to be worked) which we felt were particularly significant. 
We also listed a few trade studies which needed to be conducted very early for a 
particular program. 
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5/22/91 • Management worked up an outline of the necessary documentation to complete 
the QFD task. This outline was then broken into pieces and assigned to various 
members of the team, so that each of the full time members had a part to be written. 
This was done to establish a strong sense of ownership in the final product. 
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AniffindiiL OEUXsam Observations 

1. The right team membership is extremely important! 

• Team members need to have a vested interest in the outcome of the process. 

• Team membership should span the co mmuni ty of supporting organizations 
required for the end product. 

• Individual members should have experience in the technical and political realities 
of their organizations. 

• Individual members must be able to assume an assertive role in the process and not 
be wallflowers. 

• The member's home organization must be supportive of the process and allow him 
to devote the necessary time to the process. 

2. Management must be willing to invest the time necessary for the QFD team to reach a 

logical conclusion of its work. As a general guideline, plan on the team needing twice 
what is planned for. 

3. Management support and assurance of the usefulness and actual use of the resulting 

product is absolutely necessary. 

4. The use of "Practice Customers" to start the interview and What tree formulation process 

was helpful in working out the process and interviewing skills. 

5. We struggled to define the What Affinity/Tree before we talked to customers. The use of 

"Practice Customers" to prime the pump was a great help. 

6. The use of sub-teams to make a first cut at the scoring of the relationship of Whats and 

Hows speeds up the process. 

7. The use of Definition owners for each of the Whats and Hows worked well. W T e generally 

solicited volunteers so that people with the most familiarity with a particular area 
were used when possible. 

8. Brainstorming discussions sometimes become very frustrating, especially late in the 

afternoon. It was usually better to break off these activities for the day when this 
problem became obvious. 

9. Assignments were not always completed on schedule, aid additional time was needed to 

complete the actions. 

10. Obtaining agreement on definitions is very tedious anc. time consuming, but individual 

ownership helped speed the process. 

11. There was considerable struggle to decide which customers were most important, and 

should be interviewed. The team decided to concentrate on near term NASA program 
offices and the technology development offices. 

12. Whats and Hows should be defined as early as possible to properly score the 

relationships. Delaying this caused a great deal of confusion and misunderstanding. 
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13. Our team received a two day QFD training course immediately before beg innin g the 

QFD project. It is recommended, instead, that a five day course be taught about two 
weeks prior to the QFD project. 

14. The What list can vary according to the QFD purpose. Our What list container only 

those derived from customer interviews. A complete What list would cont«-.n all the 
higher level functions of a deliverable end item. 

15. The Definitions created by the team for Whats, Hows, and the subject terminology, were 

among the most valuable products of the study. They clarified thinking, were 
educational, and resolved ambiguities. An example was the distinction between 
"automatic" and "autonomous". 

16. Prior to customer interviews, the team made a very complete functional decomposition 

of RPOC functions. This tree identified the procedural steps normally taken in 
defi-dng RPOC functional requirements. It also contained the functional requirements 
and related hardware or software. The functional requirement section included 
reliability, environment, life of product, and testing requirements. Making this list 
clarified the thinking of the team and gave them confidence in the completeness of the 
RPOC subject matter. Future QFD projects may want to follow this practice. For future 
space vehicle programs, this preliminary functional decomposition could serve as a 
checklist of things to be done during the design effort, and as an outline of a 
procurement specification. 

17. Isolation from team members normal duties is essential. The work area for the QFD 

meetings was isolated from the team members' regular offices by being in an off-site 
NASA building. This isolation avoided interruptions and distractions. The QFD 
meeting area had two conference rooms, a computer room, and a work table. This 
spacious work area permitted breaking up into smaller teams upon occasion. 

18. Computer equipment support is very helpful in conducting team discussions. Our 

equipment included four desktop computers, a viewgraph projector and screen, and 
an LCD overlay projector that attached to a computer and used the viewgraph projector 
to display the computer on a screen. This permitted real time discussions of changes 
and consensus faster because all team members could see what was under discussion. 
Most team members returned to their offices tc do word processing. 

19. The team was relieved of their other duties by their supervisors, except that one day per 

week was allocated to non-QFD tasks. 

20. At first the team was puzzled about whether to categorize a RPOC feature as a What or a 

How. By definition, a How is a solution for a What. But in a certain sense, every How 
was itself a customer need; that is, a What. It was finally realized that Whats and 
« Hows are a relationship between two features. Each How is also a What, at the next 

level, with its own set of subordinate Hows, and so on, level by level. Tims, there is a 
branching of What-How relationship^, similar to a decomposition of functional 
requirements. In the QFD study guides, this concept is represented by a chain of 
House of Quality diagrams, in which the Howe of a preceding House become the Whats 
of the next House. 
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21. Customer interviews should be recorded on audio tape. Tape would have verified that no 

information was lost or overlooked. 

22. In a similar manner, the team discussions were outstanding commentaries, vigorous 

and innovative. It is regretted that these discussions were not recorded by audio or 
video; useful and well reasoned material was not captured. 

23. The names of the customers interviewed, the transcriptions of the interviews, and the 

Whats and Hows derived from a particular customer, should not be published. This 
preserves the confidentiality of the customers, and allows them to freely and openly 
express their opinions. 

24. E°ch customer should be provided a summary of his interview. He then can provide 

corrections where needed. 
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Appendix J. Qunntitetivft Valuefi of Teciminal Solution* 


Technical Solution Method MtiBUftmtOt Tiffltt YllU« 


Use Incremental 
Design Approach 

Planned design growth 

n interim design steps 

Draper method 

if hooks & scars 

Review STS/SSF 

Maturity of technology 

OAET technology level 

9 

Step-wise verification 

% requirements met 

o reach 100 

Uaa Slmplr Systems 

degree of complexity 

ft of moving parts 

Current RPOC 

* steps in operation 

Current RPOC 

Multi-use of elements 

ft of different elements 

Numeric might be a ratio oi 
multi-use events to number 
of different elements. 
Object is to maximize ratio. 

Estimated reliability 

Calculated MTBF 

numeric 

Uaa Failure 

Raalatant 

Components 

H>gh reliability 

MTBF or P(1ailure) 

Breakdown target goals by 
component or at least 
element to answer reliability, 
schedule and cost 
questions. 

Available oarts 

Procurement lead time 

T..7ie in Days or Weeks 

Affordable 

Cost to increase reliability 
vs. redundancy 

???? 

Use certified sources 

If of questionable suppliers 
for parts 

???? 

Uaa Redundant 
Components/In forma 
lion 

Efficient use of redundancy 

ft redundant components 

ratio 

ft redundant pathsfminimize) 

Probability of success 

Efficient use of functional 

It of ways to derive 

numeric 

redundancy 

required information 

Failure modes & effects 
analysis (FMEA) 

???? 

???? 

Uaa Conaarvativa 
Margins 

Ability to function when off- 
nominal 

<f of parameters off-nom 

numeric 

Component usage 
-’roperties 

<f of std dev off-nom 

numeric 

% derating 

numeric 

Uaa Standardized 

Interfaces 

If different interfaces 

numeric 


ratio of standard to total 
number of interfaces 

ratio 

If of interface requirements 
documents 

numeric 

Uaa friendly 
Interfaces 

Comfortable, consistent, 
easy to use, intuitive 

ft training hours req 

numeric 

User survey for feedback 

If of chanqes requested 

numeric 

Operability of controls 

ff of changes requested 

numeric 

Define System 
Requirements for 
Minimum Training 

Ease of use 

(f training hours req 

numeric 

Operability of controls 

If of Operations reviews 

numeric 

Concurrent Ops/Sys reqmts 
definition 

If of meetings 

numeric 

Use Concurrent 
Engineering 

Processes 

Maximize the number of 
multifunctional 
interdisciplinary teams 
lormed 

Number of teams 

Maximum 

Minimize the number of 
required design changes 

Number of design changes 

Minimum 

Minimize quality loss 

% quality loss 

Minimum 

Maximize customer 
satisfaction 

Number of complaints 

Minimum 


Technical Solution 


Method 


Measurement 


Tiratt Yalui 



Minimize product 
development time 

Months to devo'op product JMinimum 

Maximize number o? 
competitive benchmark 
studies 

Number ot st ..as 

Maximum 

Minimize product cost per 
unit 

Cost per unit 

Minimum 

Perform Survey of 
State<of-the-Art 
RPOC Capabilities 

Level of Participation 

% of Surveyed responses 

95% 

% of Questions Answered 

99% 

Quality of Data Obtained 

% of Responses Providing 
the requested Details 

85% 

Build Databases 

dumber of Contributors 

% Increase in Contributors 

20%/Yr (5 Yrs) 

dumber of Users 

% Increase in Users 

25%/Yr (5 Yrs) 

Develop Integrated 
Technology Plan 




Develop Advanced 
Senaora 




Develop Advanced 
Algorithms 




Develop Improved 
Docking Mechanisms 
& Facilities 




Define 

Resupply/Return 

Requirements 

Minimize the number of 
requirements changes at 
croqram phases 

Number of requirements 
changed 

Minimum 

Develop resupplv/return 
requirements analysis 
croqrams 

Number of programs 

>1 

Develop Traffic 
Control Strategy 

Prepare concept document 

Document 

1 

Minimize average 
contamination per vehicle 
per unit of time 

Average angstroms 
contamination per vehicle 
per unit of time 

TBD 

Minimize the amount of 
propellant per vehicle per 
unit of time required for 
traffic manaqement 

Mass of propellant per 
vehicle per unit of time 

TBD 

Maintain the required mean 
separation required per 
vehicle 

Mean range between 
vehicles 

TBD 

Maximize the number of 
vehicles controlled 

Number of vehicles 
controlled 

Maximum 

Minimize the number of 
required interactions per unit 
of time 

Number of interactions 

Minimum 

Define Operating 
Modes 

Document defining 
guidelines for mode 
selection 

Document 

1 

Traceability to miss, on 
requirements 

Number of satisfied 
requirements 

Maximum 

Minimize training 
requirements 

Training hours required 

Minimum 

Define Operating 
Zones 

Prepare zone definition 
document 

Document 

1 

Minimize the number of 
zones 

Number of zones 

Minimum 

Maximize the number of 
operations allowed in each 
zone 

0peration3/zone 

Maximum 
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Maximize the number of 
vehicles allowed '■er zone 

Vehicles/zone 

Maxir um 

Early Definition & 
Maturity of 
Raqulramanta 




Improve System 
Requirements 
Traceability Process 




Provide Effective 
Telemetry/Commend/ 
Navigation 
Infrastructure 

Calculate percentage of up 
and down link requirements 
(or total requirements) 
satisfied by current 
infrastructure 

Percentage of Total 
Requirements (kbps/total 
<bps x 1 00) 

100% 

Reduce/Standardize 
Mission Dependent 
Reconfiguration 

Minimize the total man-hours 
spent on Mission Dependent 
Reconfiguration for a fliqht 

Man-Hours per Flight Hours 
for a Flight 

Minimize 

Minimize the total man-hours 
spent on Mission Dependent 
Reconfiguration for a Fiscal 
Tear 

Man-Hours per Flight Hours 
per Year 

Minimize 

Reduce/Standardize 
Flight Software 
Reconfiguration 

Minimize the total man-hours 
spent on Software 
Reconfiguration for a Fiscal 
Year 

Man-Hours per Right Hours 
oer Year 

Minimize 

Reduce/Standardize 
Flight Turnaround 
Reconfiguration 

Minimize the total man-hours 
.spent on Turnaround 
Reconfiguration for a flight 

Man-Hours per Flight Hours 
for a Flight 

Minimize 

Minimize the total man-hours 
spent on Turnaround 
Reconfiguration for a Fiscal 
Year 

Man-Hours per Right Hours 
per Year 

Minimize 

Perform Functional 
Analysis of All RPOC 
Systems 

Number of requirements, 
Systems, Functions, and 
Sub-functions 

Change Traffic 

Decrease Change Traffic 

Develop Trsiectory 

Approach 

Techniques 

Minimize fuel usage 

AV used 

S(1 + x)100% of nominal 
where (x 2 0; x is TBD) 

Minimize contamination 

Deposit at TBD m 

g 

sTBD angstroms/'enr 

Keep structural loads at an 
acceptable level 

Peak load at TBD m 

STBD 

Keep software costs low 

Source lines of code 

sTBC 

Apply Expert 
Systems to RPOC 

Number of Systems & 
Functions Applied to 

% of Total Functions 

00% 

Requirements Satisfied 

% of Total Requirements 

B0% 

Workload 

Decreasing Workload 

50% Reduction in Workload 
(on-board and ground) 

Develop Algorithms 
for Rendezvous 

Minimize fuel usage 

&V used 

s(1 + x)100% of nominal 
where |xzO;x is TBD) 

Control dispersions 

Dispersions 

sTBD m at range TBD m 

Maximize nav accuracy 

Navigation errors 

sTBD m at range TBD m 

Minimize computation 

Execution time 

STBD sec 

Keep software costs low 

Source lines of code 

STBD 
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Maaauramant 

Tftratl .YilHt 

Develop Attitude and 
Translational Control 
Systems to Minimize 
Plume Impingement 
and Contamination 

Minimize contamination 

Deposit at TBD m 

;TBD angstroms/cm 2 


<eop structural loads at an 
acceptable level 

3 eak load at TBD m 

>TBD 

Perform Systems & 
Technology Trade 
Studies 

Maximize Total Man-Hours & 
-acility Hours Available to 
Perform Trade Studies 

Total of Man-Hours & facility 
Hours 

Maximize 

Perform Simulations 
Non-Real Time 




s erform Simulation - 
3eai Time 




Perform Hardware 
Evaluations 




Perform Statistical 
Analyses 

Maximize Total Man-Hours & 
-acility Hours Available to 
3 erform Statistical Analyses 

Total of Man-Hours & Facility 

Hc.rs 

Maximize 

Automate Design 
Process of RPOC 
Systems 




Use Automatic Codn 
Generation 




Automate Mission 
Planning 




Conduct Shuttle 
Flight 

Demonstrations 

Document defining criteria 
lor selection of STS flight 
demonstrations 

Document 

1 

Maximize number of 
scheduled, approved 
detailed test objectives 
(DTOs) per time period 

Number of scheduled DTOs 

Maximum 


Maximize the number of 
DTOs completed per time 
period 

Number of DTOs completed 

Maximum 


Maximize number of 
technology areas 
demonstrated per time 
period 

Number of technology areas 

Maximum 

Conduct Unmanned 
Vehicle Flight 
Demonstrations 

Document defining criteria 
lor selection of unmanned 
flight demonstrations 

Document 

1 

Maximize number of 
scheduled, approved 
unmanned detailed test 
objectives (DTOs) per time 
period which support 
validation not otherwise 
possible 

Number of scheduled DTOs 

Maximum 


Maximize the number of 
approved unmanned DTOs 
completed per time period 

Number of DTOs completed 

Maximum 


Maximize number of 
tec*'''otogy areas 
de. ’strafed per time 
period 

Number of technology areas 

Maximum 

Conduct Multi- 
Vehicle Flight 
Demonstrations 

Document defining criteria 
lor selection of multi-vehicle 
(light demonstrations 

Document 

1 
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Meaeuremant Target Yalta 



Maximize number of 
scheduled, approved multi- 
vehicle detailed test 
objectives (DTOs) per time 
period which support 
validation not otherwise 
possible 

Number of scheduled DTOs 

Maximum 

Maximize the number of 
approved multi-vehicle DTOs 
completed per time period 

Number of DTOs completed 

Maximum 

Maximize number of 
technology areas 
demonstrated per time 
period 

Number of technology areas 

Maximum 

Conduct Prototype 
System Ground 
Tests 

Quick Implementation 

Meet Milestones 

??? 

Model Fidelity 

% of Required Models 

??? 

Redesign 

% of Rework Required for 
New Applications 

??? 

Testing 

% of Final Testing Achieved 

??? 

Conduct G'cinid 
Tests of Flight 
Hardware 
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